System and method to publish information from servers to remote monitor devices

ABSTRACT

To assist in monitoring the intelligent messaging network, a system and method for publishing logging and status information from the servers is provided. A list of available servers accessible for monitoring by persons, devices, and applications via a remote monitor device can be provided. The remote monitor device may forward selected servers from the list of available servers in which they are interested. Also, particular information about the selected servers can be requested. Access to certain servers and information may be restricted to those with authorization. Authorization can be verified by the use of digital certificates. The requested information can then be gathered and provided to authorized persons or devices. Typically, the information includes logging and status information from the servers. The information can be provided as an XML page and viewed using, for example, a standard web browser. Further, if the information is provided to the remote monitor device as an XML page, a standard XML parser may be used to extract particular information from the XML page.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

[0001] The present invention is a continuation-in-part application ofU.S. patent application Ser. No. 09/494,553, entitled “A MessagingMethod and Apparatus For Sending and Receiving Messages In A ClientServer Environment Over Multiple Wireless Networks,” to Zombek, et al.,filed on Jan. 31, 2000, of common assignee to the present invention, thecontents of which are incorporated herein by reference in theirentireties.

[0002] The present invention is related to a Continuation in Part U.S.patent application Ser. No. to be assigned, entitled “A Messaging Methodand Apparatus For Sending and Receiving Messages In A Client ServerEnvironment Over Multiple Wireless Networks,” to Zombek, et al., filedOct. 24, 2000, of common assignee to the present invention, the contentsof which are incorporated herein by reference in their entireties.

FIELD OF THE INVENTION

[0003] The present invention relates in general to the field ofcommunications and more particularly to messaging between client devicesand servers over multiple wireless networks that use different accessprotocols.

BACKGROUND OF THE INVENTION

[0004] Recent advances in hardware and communication technologies havebrought about an era of client computing over wired and wirelessnetworks. The proliferation of powerful notebook computers and wirelessclient devices promises to provide client end users with network accessat any time and in any location over various networks, including theInternet. This continuous connectivity allows users to be quicklynotified of changing events, and provides them with the resourcesnecessary to respond in realtime even when in transit. For example, inthe financial services industry, online traders and financialprofessionals may be given the power to access information in real-time,using wireless client devices.

[0005] Conventionally, however, developers of complex, wirelessmessaging solutions have been forced to develop applications that arespecific to various device types and network access protocols in diverseenterprise architectures and platforms. In other words, conventionalclient computing solutions have been largely platform-specific,network-specific, or both. For example, messages may be generated by awide variety of applications running on a wide variety of clientdevices, such as Palm computing platform devices, Windows CE devices,paging and messaging devices, laptop computers, data-capable smartphones, etc. Depending on the type of network used by service providers,the client-generated messages may be transported over networks havingvarious access protocols, such as, e.g., Cellular Digital Packet Data(CDPD), Mobitex, dial-up Internet connections, Code Division MultipleAccess (CDMA), Global System for Mobile Communications (GSM), andReFlex. As a result, current developers of client computing solutionsmust have intimate knowledge of specific network characteristicsincluding, e.g., wireless network characteristics, protocolenvironments, and wireless links channel characteristics. Therefore,there exists a need to simplify wireless client and server applicationdevelopment environments to support the wide variety of device andnetwork dependent architectures.

[0006] Messaging Application Programming Interface (MAPI) is a messagingarchitecture and an interface component for applications such aselectronic mail, scheduling, calendaring and document management. As amessaging architecture, MAPI provides a consistent interface formultiple application programs to interact with multiple messagingsystems across a variety of hardware platforms. MAPI provides crossplatform support through such industry standards as Simple Mail TransferProtocol (SMTP), X.400 and common messaging calls. MAPI is also themessaging component of Windows Open Services Architecture (WOSA).

[0007] Accordingly, MAPI is built into such operating systems as, e.g.,Windows 95, Windows 98, Windows NT and Windows 2000, available fromMicrosoft Corporation of Redmond, Wash., U.S.A. and can be used by16-bit and 32-bit Windows applications. For example, a word processorcan send documents and a workgroup application can share and storedifferent types of data using MAPI. MAPI separates the programminginterfaces used by the client applications and the service providers.Every component works with a common, Microsoft Windows-based userinterface. For example, a single messaging client application can beused to receive messages from fax, a bulletin board system, a host-basedmessaging system and a LAN-based system. Messages from all of thesesystems can be delivered to a single “universal inbox.”

[0008] Transmission Control Protocol (TCP) is a transport layer protocolused by an application in one host to communicate with an application inanother host. This is accomplished by services provided by the protocollayers beneath the transport layer in both hosts. As aconnection-oriented protocol TCP requires the establishment of aconnection between the two hosts before two applications are able tocommunicate. TCP manages the connection and once both applications havecommunicated all required information between themselves the connectionis released as if the connection is two simplex connections as opposedto a single duplex connection. The information is transferred betweenapplications on different hosts is a byte stream. The transport layerhides message transfer details such as segmentation, ordering andduplication from the applications and provides end-to-endacknowledgement.

[0009] The Internet Protocol (IP) layer provides certain services to thetransport layer protocol including hiding the details of the physicaland data link layers and the services provided by them from thetransport layer protocol. The IP layer provides a datagram deliveryservice. A datagram is a unit of data less than an entire message. Amessage may be, for example, a file, which may be quite large. Sincethere is a maximum size for a message (or file), the message may have tobe segmented and transferred in smaller units. These smaller units arethus called datagrams. Each datagram is sent over the network as aseparate entity and may, in fact, follow separate paths to thedestination host. At the destination host, the datagrams are reassembledin proper order (usually in a buffer area) by the transport layer. Eachnode on the network sends any datagrams on to a next node onlyconsidering the final destination and only acknowledges receipt of thedatagram to the preceding node. That is, the IP layer does not provideend-to-end acknowledgement. End-to-end acknowledgement is a service ofthe transport layer protocol. Should the preceding node not receive anynode-to-node acknowledgements, the datagram or datagrams unacknowledgedwill be retransmitted. The transport layer in the destination host willalso acknowledge any duplicated datagrams (else receipt of duplicatedatagrams will continue resulting in a clogged network) and ignore them.

[0010] Routing between network nodes is accomplished by means of routingtables. These routing tables can be static or dynamic and result indatagrams being forwarded from a source host to a destination host onenode at a time. The intermediate nodes are often called “hops.”

[0011] The acronym, TCP/IP, is also used to refer to a five layerprotocol model similar to the ISO/OSI seven layer protocol model. TheTCP/IP model does not have the equivalent to layers 5 and 6 of theISO/OSI protocol model. A protocol model defines the protocol layers andthe interfaces between the layers. When implemented in software,hardware or firmware or possibly field programmable gate arrays (FPGAs),the implementation provides the actual services. This layered approachallows for ease of upgrading so long as the interface to the layerimmediately above or below is not altered. Layering also allows forcomplete substitution. For example, should a new physical medium becomeavailable then so long as the interface between layer two and layer oneremain the same, an old physical layer implementation module can beremoved and a new implementation module substituted. In the alternative,the new implementation module could be added as another option. That is,the protocol suite defines the rules and the implementation provides theservices that allow the communications to take place betweenapplications on different hosts. The implementation of the TCP layerprovides for the application to require a certain Quality of Service(QOS) as specified by a set of parameters including but not limited topriority, transmission delay, throughput etc..

[0012] Another well-known transport layer protocol is known as UserDatagram Protocol (UDP), which is a connectionless transport protocol.The basic data transfer unit is the datagram. A datagram is divided intoheader and data areas as it is for the IP layer. An additional headerover and above the IP header is used. The UDP header contains source anddestination addresses (ports), a UDP length field (the length includesthe 8 byte header and the data) and a UDP checksum. The UDP dataincludes the IP header and data. The IP layer supports UDP as aconnectionless transport protocol for use in transmitting, for example,one time request-reply type messages or applications where time is ofgreater importance than accuracy.

[0013] TCP is used by applications on different hosts to communicateover an assumed unreliable network. To accomplish such communicationmuch is added to the protocol in order to ensure that the informationtransferred over the network is valid. This addition has a cost and thatcost is increased overhead with the attendant increase in bandwidth. AUDP header is eight bytes, the TCP header is 24 bytes and an IP headeris a minimum of 20 bytes. Therefore, UDP/IP headers are a minimum of 28bytes and TCP/IP headers are a minimum of 44 bytes. This is fairly largein terms of overhead and bandwidth utilization particularly overwireless networks. There are other significant problems with usingstandard TCP/IP over wireless networks principally in the area of flowcontrol. The UDP/IP protocol combination, while not offering anyguarantees to users, is expected to be reliable. Wireless networks tend,however, by their nature to be lossy. Several solutions have beenproposed when the network is not homogeneous. That is, when the networkhas both wireless and wireline portions. One suggestion is to useindirect TCP and another is to use snooping.

[0014] Other protocols such as Serial Line IP (SLIP) and Point to PointProtocol (PPP) have been developed. SLIP is not a standard and both arefor point to point connections only so are not available for uses innetworks. CDPD vendors indicate that they provide an integrated TCP/IPstack but it is not known the cost in terms of bandwidth overhead.

[0015] Conventionally, the existing wireless protocols do not provide anend-to-end solution over multiple networks and multiple client devices.Therefore, in addition to the need for a common architecture through asingle, user friendly methodology for providing effective and reliablewireless data solutions for hand-held and laptop computing devices,wireless networks, and legacy systems, there also exists a need toefficiently and reliably communicate data using minimum bandwidth.

SUMMARY OF THE INVENTION

[0016] The present invention features a system, method and computerprogram product that in an exemplary embodiment is operative to providea multi-network transport programming interface that can enableclient/server applications to be written easily, where such applicationscan allow client applications running on client devices to communicatemessages with server applications across one or more wireless andwire-line networks. Moreover, the present invention in an exemplaryembodiment offers features for communicating such messages over wirelessnetworks efficiently, without requiring significant bandwidth, avaluable resource in wireless networks. In a further embodiment, theinvention provides for transmitting unsolicited messages from servers toconnectionless client devices.

[0017] Briefly, the present invention in an exemplary embodimentincludes a system for communicating messages in a client-serverenvironment over one or more wireless networks that can supportdifferent network protocols. In an exemplary embodiment, the system ofthe invention includes a client device operative to execute a clientapplication, and a back-end server (BES) operative to execute a serverapplication. In an exemplary embodiment, a protocol gateway (PG) canencapsulate an underlying network protocol of the plurality of wirelessnetworks. In an exemplary embodiment, a client application and theserver application can communicate messages with each other through thePG independently of the underlying network protocol of the wirelessnetwork used for such communication.

[0018] Conventional session-based transport protocols (e.g. TCP) aredesigned for LAN-based systems with little network latency. Thesesession-based transport protocol implementations are extremely chattyand were not designed to consider the amount of bytes sent over thenetwork to maintain the state of a connection.

[0019] Advantageously, the present invention, in an exemplaryembodiment, features a highly optimized semi-reliable data transportprotocol, simple network transport layer (SNTL). The transport protocolimplementation, in an exemplary embodiment, can optimize the over theair communication by using a connectionless send and receive mechanism.In addition, or alternatively, in an exemplary embodiment, the presentinvention can provide multiple compression mechanisms to reduce theamount of information that needs to be sent over the air. In anexemplary embodiment, in order to provide a reliable mechanism over aconnectionless environment, the transport protocol implementation canprovide for message segmentation and reassembly, message retries, ormessage ACK and NACK service for each supported wireless network. In anexemplary embodiment, message segments that are not acknowledged by thepeer protocol layer within the configurable time frame can be retriedautomatically by the transport protocol implementation. In order tofacilitate the request and provision of services, the interfaces betweenlayers can be clearly defined for peer-to-peer communication betweencorresponding layers of both sides of a connection. That is, theprotocol stack on each side (client and server) can be symmetrical. Thiscan allow two machines to specify how they communicate with one anotheron a level-to-level basis, rather than having to negotiate one giantprotocol for the entire network. This means that logical communicationscan occur at the peer protocol layer. On the client side for wirelesscommunications this can be called a peer wireless protocol layer. In anexemplary embodiment, the client or server applications do not need tobe concerned with segmenting the message and performing message retries.In addition to performing message retries, the transport protocolimplementation can support message duplication detection. In anexemplary embodiment, to support this reliable mechanism over aconnectionless environment, the transport protocol implementation canadd only four to six bytes to each application message. In an exemplaryembodiment, SNTL can include a novel and non-obvious hybrid protocolincluding many of the advantages of TCP but connectionless as is UDP.Further, in an exemplary embodiment, there can be less overhead than isrequired by conventional TCP.

[0020] The present invention, in an exemplary embodiment, can also use awireless connectivity middle layer gateway, which can be developed usinga wireless software development environment. The environment caninsulate a developer from the complexities of the underlying detailsrelated to devices and protocols.

[0021] In an exemplary embodiment, the environment can be packaged,advantageously, as a software development toolkit (SDK). The developercan work at the application layer by using the SDK. The SDK, in anexemplary embodiment, can include, e.g., software libraries for clientand/or server application development. The present invention, in anexemplary embodiment, can support solutions and software engineeringusing technologies such as, e.g., Windows NT/95/98/2000, Open DatabaseConnection (ODBC) compliant databases, Palm OS, and Windows CE clientdevices, and CDPD, Mobitex and dial-up networks.

[0022] Advantageously, wireless technologies and client devices canremain transparent to the data source through the use of client andserver application programming interfaces (APIs) that can supportmultiple operating environments including, for example, Palm OS, RIM,Windows 95, 98, 2000, CE and NT, UNIX, Linux, and other variations ofUNIX, etc. These well-defined APIs can use a set of portable classlibraries to aid in rapid application development. Access to theintelligent messaging network of the present invention can be viawireless client devices or via a dial-up or leased line or otherwireline connection coupled via, e.g., an Internet service provider(ISP), a network service provider (NSP), a private network, or a virtualprivate network (VPN). That is, enterprise support, can be provided forand to, wireless clients and clients that need to access the intelligentmessaging network of the present invention via a wired connection ordial-up line. This latter group of clients can be called Internet proxyclients, i.e., clients that can use a proxy server for access to theInternet. As client devices and wireless network technologies evolve,this system can ensure that data solutions are supported.

[0023] In an exemplary embodiment, the messaging system communicates amessage between a client device and servers over a plurality of wirelessnetworks, each of which is adapted to support one or more wirelessnetwork protocols. A web server communicates with the servers. The webserver can send information about the servers to remote monitor clients.The monitoring can be performed by publishing a list of availableservers to the remote monitor clients. A selection of servers isreceived from the remote monitor clients. Information about the selectedservers is dynamically generated with the web server. The dynamicallygenerated information is provided from the web server to the remotemonitor clients.

[0024] In a further embodiment, a monitoring process includes receivinga list of available servers at the remote monitor client from the webserver. A selection of servers is made from the list of availableservers. A list of selected servers is transmitted from the remotemonitor client to the web server. Information about the selected serversis received at the remote monitor client from the web server.

[0025] According to another embodiment of the invention, a remotemonitoring system is provided. A server has stored therein a serverapplication, which is adapted to be executed by the server. A pluralityof wireless networks, each of which is adapted to communicate messagesbetween the client device and the server and to support one or morewireless network protocols is provided. A protocol gateway encapsulatesa fundamental network protocol, which underlies each of the one or morewireless network protocols. At least one message router routes themessage between the protocol gateway and the server. Means for providinginformation from at least one of the server, the protocol gateway, andthe message router to a remote monitor client are also provided.

[0026] The means for providing information can comprise at least one webserver communicating with the remote monitor client and with at leastone of the server, the protocol gateway, and the message router.Furthermore, the web server may include means for compiling a list ofavailable servers, protocol gateways, and message routers and providingthis list to the remote monitor client. The means for providing can alsoinclude means for gathering requested information from at least one ofthe server, the protocol gateway, and the message router and providingthe requested information to the remote monitor client.

[0027] According to another embodiment of the invention, a computeruseable information storage medium storing computer readable programcode means is provided. The code means causes a computer to perform thesteps of: publishing a list of available servers to the remote monitorclients, receiving selected servers from the remote monitor clients,dynamically generating information about the selected servers with theweb server, and providing the dynamically generated information from theweb server to the remote monitor clients.

[0028] Thus, remote monitoring of servers in an intelligent messagingnetwork can be accomplished. Logging and status information can beobtained at remote locations to monitor and improve the performance ofthe intelligent messaging network. Further features and advantages ofthe invention, as well as the structure and operation of variousexemplary embodiments of the invention, are described in detail belowwith reference to the accompanying drawings. In the drawings, likereference numbers generally indicate identical, functionally similar,and/or structurally similar elements. The drawing in which an elementfirst appears is indicated by the leftmost digits in the correspondingreference number.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The foregoing and other features and advantages of the inventionwill be apparent from the following, more particular description of anexemplary embodiment of the invention, as illustrated in theaccompanying drawings.

[0030]FIG. 1A is a block diagram of an exemplary embodiment of acommunication system that advantageously incorporates a messaging systemaccording to the present invention;

[0031]FIG. 1B is a high level block diagram of an exemplary embodimentof the present invention including an exemplary protocol gateway coupledto an exemplary message router which is coupled to an exemplary back-endserver;

[0032]FIG. 1C is an exemplary embodiment illustrating messaging routingaccording to the present invention;

[0033]FIG. 1D is an exemplary embodiment illustrating a protocol gateway(PG) startup sequence according to the present invention;

[0034]FIG. 1E is an exemplary embodiment illustrating a message router(MR) startup sequence according to the present invention;

[0035]FIG. 1F is an exemplary embodiment illustrating a back end server(BES) startup sequence according to the present invention;

[0036]FIG. 2 is a block diagram of an exemplary embodiment of aredirector that interacts with a browser and the intelligent messagingnetwork that is part of the system of FIG. 1A;

[0037]FIG. 3 depicts an exemplary embodiment of the proprietary protocolstack of the present invention;

[0038]FIG. 4 is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to an authenticationchallenge success;

[0039]FIG. 5 is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to an authenticationchallenge failure;

[0040]FIG. 6A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a client applicationrequest to Back-End Server;

[0041]FIG. 6B is an exemplary embodiment of a flow diagram numericallydepicting a flow of multi-segment messages that corresponds to a clientapplication request to a Back-End Server;

[0042]FIG. 7A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a Back-End Serverresponse to client application;

[0043]FIG. 7B is an exemplary embodiment of a flow diagram numericallydepicting a flow of multi-segment messages that corresponds to aBack-End Server (BES) response to client application, or alternativelyan alert generated by the BES;

[0044]FIG. 8A is an exemplary embodiment of a flow diagram numericallydepicting a flow of messages that corresponds to a Back-End Server alertto client application;

[0045]FIG. 8B is an exemplary embodiment of a flow diagram depicting aflow of messages providing an exemplary hybrid alert to an alternateclient device according to the present invention;

[0046]FIG. 8C is an exemplary embodiment of a flow diagram depicting aflow of messages representing an exemplary request and alert that couldgive rise to sending of a hybrid alert according to FIG. 8B according tothe present invention;

[0047]FIG. 9A is an exemplary embodiment of a remote monitoring systemfor an intelligent messaging network;

[0048]FIG. 9B is an exemplary embodiment of a flow diagram depictingcommunication flow in a remote monitoring system; and

[0049]FIG. 10 is an exemplary embodiment of a diagram illustrating anexemplary message header according to the present invention.

DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT OF THE INVENTION

[0050] A preferred embodiment of the invention is discussed in detailbelow. While specific implementations are discussed, it should beunderstood that this is done for illustration purposes only. A personskilled in the relevant art will recognize that other components andconfigurations may be used without parting from the spirit and scope ofthe invention.

[0051]FIG. 1A depicts a block diagram of a communication system 100 thatadvantageously can incorporate the present invention including one ormore client devices 112 a-c, collectively referred to as client devices112. The client devices 112 can execute corresponding clientapplications, which can be developed to provide specific subscribersolutions. For example, service subscribers such as, e.g., client user102, as shown, can carry, e.g., Palm Pilot client devices, Windows CEbased client devices or other one-way or two-way messaging clientdevices 112 to, e.g., remain apprised of stock market activities andinitiate transactions while roaming within the coverage area of theirrespective wireless service providers.

[0052] As described in detail below, the communication system 100 cansupport an intelligent messaging network architecture (hereafterreferred to as “intelligent messaging network”) according to the presentinvention. The intelligent messaging network advantageously canincorporate a middleware service in accordance with the presentinvention that can allow for the development of client and serverapplications independent of the underlying network protocols and deviceconfigurations. The basic middleware services offered by the intelligentmessaging network architecture can include, e.g., client-serverconnectivity, platform transparency, network transparency, applicationtool support (through the use of APIs), network management, interactionwith other network services, scalability and high availability.

[0053] System Overview

[0054]FIG. 1A depicts an exemplary embodiment of the communicationsystem 100 including a detailed block diagram of the present invention.The communication system 100, in an exemplary embodiment, can beconfigured to support a wide variety of wired and wireless accessnetwork protocols via an access network 114. The access network 114protocols can include, e.g., dial-up modem, analog cellular, digitalcellular, cellular digital packet data (CDPD), Mobitex, RIM, Ardis,iDEN, personal communication system (PCS)-code division multiple access(CDMA) or time division multiple access (TDMA), global system forwireless messaging (GSM), two-way and one-way paging (e.g., ReFlex,Flex, etc.), as well as geosynchronous earth orbit (GEO) or low earthorbit (LEO) satellite network access protocols. The intelligent wirelessmessaging network of the present invention can provide networktransparency to developers of client and server applications. As such,developers do not need to concern themselves with implementation detailsof the underlying network protocols or with various platform specificencoding, such as, e.g., big-endian and little-endian.

[0055] A number of the protocol gateways (PGs) 116 a, 116 b and 116 c,collectively PGs 116, can be configured to support a specific networkaccess protocol. The PGs 116, in an exemplary embodiment, can act as aninterface between a network 114 and wide-area/local-area networks(WANs/LANs) 118 a, and 118 b. The PGs 116 can provide the flexibility tosupport multiple present and future wireless access protocols such as,e.g., GPRS. Networks 118 collectively including networks 118 a and 118b, as shown, can be coupled to network 114 by, e.g., a router 114, andcan be protected from unauthorized access through a firewall 120.Networks 118 can include, e.g., a wide area network (WAN), local areanetwork (LAN), and/or the global Internet. Among other things, networks118 can include, e.g., one or more back-end servers (BESs) 122 a. 122 b,and 122 c, collectively BESs 122, that can run server applications thatcan communicate messages with client applications running on the clientdevices 112. Via one or more message routers (MRs) 124 a, 124 b, and 124c, collectively MRs 124, these messages can be routed between the BESs122 and the PGs 116, and other network components. From the BESs 122,messages can be transmitted or delivered to, e.g., a content provider140. A specific type of BES shown as an HTTP Proxy BES 132 can be usedto send messages to an Internet server 142 such as a web server. Itshould be noted that although the present invention is described withreference to a specific exemplary architecture, a wide variety of WANsand LANs that can support wired and wireless environments are possible.

[0056] The PGs 116 can be responsible for sending and receivingapplication messages between client applications and a BES 122 that cansupport the service type of the application message. The message can berouted to the BES 122 via the MR 124 as will described further belowwith reference to FIG. 1C. For each network access protocol that theintelligent messaging network supports, a corresponding PG 116 cansupport that network access protocol. PGs 116 can communicate directlywith one or more MRs 124 using, e.g., conventional TCP/IP communicationsor a modification of TCP/IP to address flow control between wireless andwireline networks. In an exemplary embodiment of the invention, the PGs116 can use clustering for, e.g., redundancy, scalability andload-balancing of incoming IP traffic across all the nodes within aconfigured cluster. In an exemplary embodiment, PGs 116 can provide loadbalancing by providing traffic to MRs 124 in, e.g., a round-robinfashion, which can, e.g., transmit to least recently used MR 124. Underthis arrangement, client applications can be configured to communicateto a single virtual IP address of the PG 116 cluster. Advantageously,this can provide the intelligent messaging network the flexibility todynamically start and stop the PGs 116 without disrupting service.Typically, the PGs 116 can run outside of the firewall 120. However, theintelligent messaging network architecture of the present invention doesnot preclude the PGs 116 from running inside an enterprise firewall 120.It will be apparent to those skilled in the art that alternativeconfigurations can also be used within the spirit and scope of thepresent invention.

[0057] The BESs 122 and MRs 124 can each have access to correspondingBES and MR databases (DBs) 126 and 128, respectively, which can storeserver application and message routing parameters. Alternatively, ashared database can be used to store information on an auxiliary memorydevice such as, e.g., a storage area network (SAN). The BES DB 126 andMR DB 128 can each maintain a common pool of information amongst theentire group of network servers. In an exemplary embodiment, thisinformation, which can be independent of any specific messagingapplication, can be stored and accessed from a structured query language(SQL) database.

[0058] In order to assist network administrators in managing theintelligent messaging network, the intelligent messaging networkarchitecture can incorporate one or more simple network managementprotocol (SNMP) management consoles 130 a, 130 b, and 130 c,collectively SNMP console 130, as the mechanism for network management.SNMP is a standard network management protocol widely used inconventional TCP/IP networks. The console 130, e.g., can receive SNMPalerts. In an exemplary embodiment, a customer's SNMP console 130 can be“hooked” into, including such data as might reside in, e.g., amanagement information base (MIB) 134 a. The SNMP console 130 can beused to easily and effectively manage the intelligent messaging networkof the present invention. In addition to providing SNMP support, theintelligent messaging network can provide network administrators a toolto monitor the health of the network. An SNMP console 130 can be placedin a network operations center (NOC) to advantageously centrally managethe intelligent messaging network of the present invention.

[0059] An HTTP Redirector 106 can enable off-the-shelf web browsers suchas, e.g., browser 104, to send and receive requests, such as, e.g.,hypertext transfer protocol (HTTP) requests, over the intelligentmessaging network. As described later, the HTTP Redirector 106 can workby intercepting HTTP requests from the browser 104 and can redirect themover the intelligent messaging network for fulfillment by an intelligentmessaging network HTTP proxy back end server 132 a, 132 b, or 132 c,collectively HTTP proxy back end servers (HBES) 132, which in turn canforward messages on to, e.g., other Internet servers 142. While theintelligent messaging network can provide a set of advanced services,the network can also offer support for external legacy services thatmight already be in use by an organization. By supporting other vendorservices such as, e.g. security, and databases, the intelligentmessaging network can fit into an existing legacy networkingenvironment, thereby allowing organizations to use their existingnetworking environment.

[0060] An Exemplary Implementation Embodiment of the Present Invention

[0061] In an exemplary implementation embodiment of the presentinvention, the Intelligent Messaging Network of the present inventioncan use an Aether Intelligent Messaging (AIM) Network (also referred toas AIM.net) developed by Aether Systems Inc., of Owings Mills, Md.,U.S.A., the assignee of the present invention.

[0062] In an exemplary implementation embodiment, the BES 122 can be anAether Back End Server (ABES) available from Aether Systems Inc., ofOwings Mills, Md., U.S.A.

[0063] In an exemplary implementation embodiment, the PG 116 can be anAether Protocol Gateway (APG), also previously referred to as a frontendserver (FES), available from Aether Systems Inc., of Owings Mills, Md.,U.S.A.

[0064] In an exemplary implementation embodiment, the MR 124 can be anAether Message Router (AMR) available from Aether Systems Inc., ofOwings Mills, Md., U.S.A.

[0065] An exemplary embodiment of the MR DB 128 is an AIM databaseavailable from Aether Systems, Inc. of Owings Mills, Md., U.S.A.

[0066] In an exemplary implementation embodiment, the SNMP Console 130can be an Aether SNMP Network Management Console available from AetherSystems Inc., of Owings Mills, Md., U.S.A., which can include an SNMPcompliant network management application and hardware system platform.

[0067] In an exemplary implementation embodiment, the HTTP Proxy BackEnd Server 132 can be an Aether HTTP Proxy Back End Server availablefrom Aether Systems Inc., of Owings Mills, Md., U.S.A.

[0068] It will be apparent to those skilled in the relevant art thatalternative implementations incorporating alternative or additionalcomponents, systems, operating systems, and applications could also beused within the spirit and scope of the present invention.

[0069] Software Development Environment

[0070] The intelligent messaging network, in an exemplary embodiment,can provide multiple software development kits (SDKs) to assist, e.g.,engineers in developing client and server applications. The SDKs cancontain a consistent set of APIs and a set of platform specificlibraries for all intelligent messaging network supported platforms andnetworks. In addition to the SDKs, the intelligent messaging network canprovide developers a resource kit including a set of tools to assist thedevelopers when designing, implementing, and testing their client andserver applications.

[0071] As described later in detail, the intelligent messaging networkcan provide, in an exemplary embodiment, a mobile client and server SDKenvironment to assist engineers developing client applications and BESs122. The SDKs can provide an easy to use API and a set of platformspecific libraries to perform, e.g., compression, network managementservices, server-to-server communication, serverregistration/de-registration, and reliable message transport services.

[0072] I. Common Network Services

[0073] In an exemplary embodiment, all of the servers, PGs 116, MRs 124,BESs 122 can use, e.g., Windows NT 4.0 as their operating systemavailable from Microsoft Corporation of Redmond, Wash., U.S.A. Althoughalternative operating systems can be used in alternate embodiments, aswill be apparent to those skilled in the art, functionality of thepresent invention will be described in an exemplary Windows NT v.4.0environment. All the servers provide a set of common services,including, e.g.,:

[0074] network management;

[0075] NT event logging;

[0076] message trace logging;

[0077] run as NT services;

[0078] server registration;

[0079] server de-registration; and

[0080] server-to-server TCP/IP communication.

[0081] The intelligent messaging network server SDK can encapsulate theimplementation of these core functions via application programminginterfaces (APIs) to insulate application developers from the hardware,software and protocol details of the underlying platforms. Providedbelow is a description of exemplary common services.

[0082] A. Network Management Service

[0083] All intelligent messaging network servers can support thestandard SNMP GET, SET, and GET NEXT operations. In addition, theintelligent messaging network servers can generate SNMP traps fornotifying a network administrator of a critical event. The intelligentmessaging network Server SDK can provide a common MIB, for basic controland status-handling that is shared by all the intelligent messagingnetwork servers. In addition, the intelligent messaging network serverSDK can provide a MIB for each supported server type (i.e. PG 116, MR124, HTTP Proxy Back End Server 132, and BES 122). Developers developingBESs 122 can define custom MIBs to support functions specific to theirapplication needs and can register the custom MIBs in a registered MIBsdatabase 134. Registration of a custom MIB with the SNMP console 130 canbe encapsulated by a set of network management APIs provided by theintelligent messaging network server SDK.

[0084] B. NT Event Logging Service

[0085] All intelligent messaging network servers can log criticalinformation (e.g., start/stop time, and critical errors) to the NT eventlog on a corresponding platform on which they are running. Developersdeveloping BESs 122 can log application specific events to the NT eventlog via APIs provided by the intelligent messaging network server SDK.

[0086] C. Message Trace Logging Service

[0087] All intelligent messaging network servers can optionally loginbound., outbound, and system events on the platform on which they arerunning. Developers developing BESs 122 can log application specificinformation to an application-info-log via APIs provided by theintelligent messaging network server SDK. In this way, developers arenot required to know the implementation details of how to log a messageto the inbound, outbound, or system-info-logs.

[0088] D. Run as NT Service

[0089] In an exemplary embodiment of the invention, all intelligentmessaging network servers can run as NT services. Rather than havingeach server implement the necessary code to run as an NT service, autility program called AimServiceAny can be that can wrap NT servicefunctionality around each intelligent messaging network serverexecutable. The benefits of running a server as an NT service caninclude the following advantages:

[0090] Automatic Start on Reboot—Conventionally, when a reboot of amachine is necessary, the user re-booting can also log on and manuallystart any servers that need to be running on the machine. With anAutoStart function provided by the AimServiceAny, each intelligentmessaging network server running as an NT service can automaticallyrestart before the user logs on. This feature can be useful if, forexample, the platform reboots at night without human intervention.

[0091] No NT Logon Required to Run—As an added security measure,intelligent messaging network servers can run without having anyonelogged onto the machine and, thus, can prevent unauthorized users fromaccessing the platform and the servers.

[0092] Network Management Mechanism—In addition to SNMP, running as anNT service provides an additional simple network management capabilityby using a remote SvrMgr utility provided on all NT servers to monitorand start/stop intelligent messaging network services running anywhereon the network.

[0093] Startup Dependencies—An NT service can depend on the presence ofother services before it is allowed to start (e.g. some intelligentmessaging network servers depend on the fact that an SQL database serveris running as well as possible server-to-server dependencies).

[0094] E. A Mechanism for Providing Discovery Services For ServersDuring Startup Sequence

[0095] The intelligent messaging network can include various serversincluding, e.g., the following:

[0096] 1. PGs 116;

[0097] 2. MRs 124; and

[0098] 3. BESs 122.

[0099] The simplest instance of an intelligent messaging network caninclude a server of each of the three types coupled together as depictedin the exemplary embodiment of FIG. 1B.

[0100]FIG. 1B depicts, in an exemplary embodiment, a high level blockdiagram 136 of the present invention including, e.g., one or more PGs116 a-c coupled to one or more MRs 124 a-c, which are in turn, coupledto one or more BESs 122 a-c.

[0101] Each server-to-server connection can include a TCP connection. Asindicated in block diagram 136, PGs 116 a-c can be coupled to MRs 124a-c; MRs 124 a-c can be coupled to PGs 116 a-c and BESs 122 a-c (orHBESs 132 a-c); and BESs 122 a-c (or HBESs 132 a-c) can be coupled toMRs 124 a-c. Server startup logic can include, e.g., starting theservers 116, 122, and 124 in any order as each server can attempt tofind the server(s) of the required type to which it is to be coupled.The server start sequence, in an exemplary embodiment, can proceed asfollows:

[0102] 1. Upon start-up, an intelligent messaging network server 116,122 and 124 can create a TCP “listener” socket. The TCP listener socketaccepts connection requests from other intelligent messaging networkservers 116, 122 and 124.

[0103] 2. The intelligent messaging network server then registers thefollowing information about the server in the intelligent messagingnetwork MR database 128:

[0104] The IP address of the server and the port that the server islistening on for new connections;

[0105] The server's intelligent messaging network Domain; and

[0106] An intelligent messaging network Domain is a text string (e.g.“MyTestDomain”) that allows multiple intelligent messaging networks torun on the same physical network without interfering with each other. Anintelligent messaging network server can only connect to otherintelligent messaging network servers in the same domain.

[0107] The server's server type e.g.,: PG 116, MR 124, or BES 122.

[0108] 3. After the server registers itself in the MR database 128, theregistering server can obtain a unique database registration identifier(ID) and then can search the MR database 128 for other registeredservers in the server's intelligent messaging network domain and of theappropriate type; e.g., PGs 116 can search for MRs 124 in their domain,MRs 124 can search for PGs 116 and BESs 122, BESs 122 can search for MRs124.

[0109] 4. In the simplest intelligent messaging network, each server116, 122 and 124 can find one instance of each peer type to which itconnects. However, the intelligent messaging network can allow multipleservers of each type to run within a domain in order to improveperformance and redundancy. For example, in an exemplary embodiment, ifthere are 2 PGs 116 and 3 MRs 124, each PG 116 can be coupled to each ofthe MRs 124. For each peer server it finds in the database 128, theintelligent messaging network server can attempt to couple itself tothat server on the peer server's TCP listener socket.

[0110] 5. If the intelligent messaging network server 116, 122 and 124successfully connects to a peer, establishing a TCP connection, the twocoupled servers can then perform an intelligent messaging network“connection handshake” in order to verify the validity of theconnection. The connection handshake can include the following sequence:

[0111] a) The connecting server can send an intelligent messagingnetwork ServerConnect message to the peer server. This message cancontain the connecting server's unique database registration ID(obtained when the server first registered in the database, see step 2above). The connecting server can then wait a specified amount of timefor a reply from the peer server.

[0112] b) The peer server can receive the intelligent messaging network“connection message” and can verify that the version included as part ofthe intelligent messaging network message is compatible with its owncommunications version and that the message is indeed an intelligentmessaging network connection message. If the version is incorrect or themessage is not a connection message, the peer server can terminate theTCP connection. If the peer server accepts the connection message it cansend an intelligent messaging network connection message back to theconnector in reply.

[0113] c) When the connecting server receives a “connection replymessage” the connecting server can also verify the message version andtype and can either keep the connection open, or close the connectionif, e.g., the version and type verification fail.

[0114] d) If the connecting server does not receive an intelligentmessaging network connection reply message within the specified timewindow, the connecting server can assume that the peer server is, e.g.,not a valid intelligent messaging network server, or is functioningimproperly and so it can close the TCP connection to the peer server.

[0115]FIG. 1C is described below after FIG. 1F relating to MR 124.

[0116] PG Startup Sequence

[0117] FIG. ID depicts a block diagram 144 illustrating an exemplaryembodiment of discovery services message flow for a PG 116 startupsequence. The discovery service flow can begin with step 146.

[0118] In step 146, the PG 116 can use registration services providedby, e.g., the intelligent messaging network server SDK to register thePG 116 with the intelligent messaging network by adding an entry to aRegisteredServers table in the MR database 128.

[0119] From step 146 flow can continue with step 148.

[0120] In step 148, the PG 116 can use registration services provided bythe intelligent messaging network server SDK to enumerate the list ofall the MRs 124 registered with the intelligent messaging network in,e.g., the same domain. From step 148, flow can continue with step 150.

[0121] In step 150, using an IP address and listener port for each ofthe MRs 124, the PG 116 can use communication services provided by theintelligent messaging network server SDK to establish and manage aTCP/IP connection with each of the MRs 124 contained in the enumeratedlist. When a PG 116 couples itself to the MR 124, the MR 124 can add thePG 116 to its RegisteredServers cache and can begin to start forwardingmessages to the PG 116. If a connection attempt fails, the PG 116 canre-attempt to connect to the MR 124, according to an exemplaryembodiment of the present invention.

[0122] MR Startup Sequence

[0123]FIG. 1E depicts a block diagram 152 illustrating an exemplaryembodiment of discovery services message flow for a MR 124 startupsequence. The discovery service flow can begin with step 154.

[0124] In step 154, the MR 124 can use registration services provided bythe intelligent messaging network server SDK to register itself with theintelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. It will be apparent tothose skilled in the art that an alternative database could be used.From step 154, diagram 152 can continue with step 156.

[0125] In step 156, the MR 124 can use registration services provided bythe intelligent messaging network server SDK to enumerate a list of,e.g., all PGs 116 and PSs 122 registered with the intelligent messagingnetwork. From step 156, diagram 152 can continue with step 158.

[0126] In step 158, using the IP Address and listener port for each PG116, the MR 124 can use communication services provided by theintelligent messaging network server SDK to establish and manage aTCP/IP connection with, e.g., each PG 116 contained in the enumeratedlist. When a MR 124 couples to a PG 116, the PG 116 can add the MR 124to its Server Connections cache and can begin to start forwardingmessages to the Message Router. From step 158, diagram 152 can continuewith step 160.

[0127] In step 160, using the IP address and listener port for each BES122, the MR 124 can uses communication services provided by theintelligent messaging network server SDK to establish and manage aTCP/IP connection with each BES 122 contained in the enumerated list.When a MR 124 couples to a BES 122, the BES 122 can add the MR 124 toits Server Connections cache and can begin to start forwarding messagesto the MR 124.

[0128] BES Startup Sequence

[0129]FIG. 1F depicts a block diagram 162 illustrating an exemplaryembodiment of discovery services message flow for a BES 122 startupsequence. The discovery service flow can begin with step 164.

[0130] In step 164, the BES 122 can use the registration servicesprovided by the intelligent messaging network server SDK to registeritself with the intelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. From step 164, diagram162 can continue with step 166.

[0131] In step 166, the BES 122 can use registration services providedby the intelligent messaging network server SDK to enumerate the listof, e.g., all MRs 124 registered with the intelligent messaging network.From step 166, diagram 162 can continue with step 168.

[0132] In step 168, using the IP address and listener port for each MR124, the BES 122 can use the communication services provided by theintelligent messaging network server SDK to establish and manage aTCP/IP connection with each MR 124 contained in the enumerated list.When a BES 122 can couple to a MR 124, the MR 124 can add the BES 122 toits RegisteredServers cache and can begin to start forwarding messagesto the BES 122. If the connection attempt fails, the BES 122 canreattempt to connect to the MR 124.

[0133] F. Server Connection Race Condition Handling

[0134] If two peer intelligent messaging network servers are started atapproximately the same time, it is possible that each will attempt toconnect to the other, thus establishing two connections between themrather than a desired single connection. The possibility of collidingconnection requests is the reason that during the connection handshake,the servers exchange unique database registration IDs. Each server canuse the unique database registration ID to keep track of which serversit is already connected to, so that if server A establishes a connectionto server B, and due to race conditions server B immediately establishesanother connection to server A, server A can use the unique databaseregistration ID passed by server B to realize that it already has aconnection to server B and thus can drop the new connection.

[0135] G. Server Registration Service

[0136] When an intelligent messaging network server is started, it canregister itself with the network by adding an entry to aRegisteredServers table in the intelligent messaging network MR database128. This can enable other intelligent messaging network servers tolocate one another on the network. An API provided by the intelligentmessaging network server SDK can allow for registering the followingserver attributes in the intelligent messaging network MR database 128:

[0137] Server Class—PG 116, BES 122, and MR 124;

[0138] Server Type—PGs 116 types can include CDPD, Mobitex and ISPdialup. BES 122 types can depend on the server application;

[0139] Packet Header Version—can indicates the version of the packetheader that the server supports; and

[0140] IP Address and Listener Port—can indicate the IP address and theListener port number to be connected to by other servers in order tocommunicate with this server.

[0141] H. Server De-Registration Service

[0142] When an intelligent messaging network server is stopped, it cande-register itself from the network by removing its entry from theRegisterServers table in the intelligent messaging network MR database128. An API can be provided by the intelligent messaging network serverSDK to de-register a server in the intelligent messaging network MRdatabase 128.

[0143] I. Server-to-Server TCP/IP Communications Service

[0144] In an exemplary embodiment of the invention, intelligentmessaging network servers can communicate with each other over a TCP/IPsocket connection. APIs provided by the intelligent messaging networkserver can encapsulate the creation, management, and sending/receivingof data over the socket connection.

[0145] II. Server-Specific Services

[0146] In addition to the above-described common set of services, eachserver can also provide additional services that can be specific to thefunctionality of the server. Thus, in an exemplary embodiment, theintelligent messaging network architecture can include various coresoftware components that can run on, e.g.,:

[0147] PG 116;

[0148] MR 124;

[0149] BES 122;

[0150] HTTP Proxy Back End Server 132; and

[0151] SNMP Management Console 130.

[0152] A. Protocol Gateway PGs Operation and Services

[0153] Using the registration services provided by the intelligentmessaging network server SDK, the PGs 116 can follow a predefined startup sequence to register itself with the intelligent messaging network.Each PG 116 can add an entry to the RegisteredServers table in theintelligent messaging network MR database 128 and can enumerate the listof all MRs 124 registered with the network in the same domain. Based onthe IP address and listener socket for each MR 124, the PG 116 canestablish and manage a TCP/IP connection with each MR 124 contained inthe enumerated list. When a PG 116 connects to an MR 124, the MR 124 canadd the PG 116 to its RegisteredServers cache and can begin forwardingmessages to the PG 116. If, however, the connection attempt fails (e.g.,there is a timeout), the PG 116 can re-attempt to connect to the MR 124after a configurable time period.

[0154] In addition to the above-described common services, the PGs 116can be responsible for supporting the following specific services:

[0155] 1. Encapsulate the Network Communications Protocol

[0156] Each PG 116 can encapsulate the underlying wireless networkaccess protocol so that it is transparent to MR 124 and BESs 122. As aresult, when the MR 124 receives a message from a PG 116, it is unawareof the underlying network access protocol used for communicating themessage.

[0157] 2. Message Segmentation

[0158] All messages to be transmitted over the network that exceed apredefined segment size can be segmented into multiple message segments.

[0159] 3. Message Re-Assembly

[0160] All incoming message segments (except the last segment tocomplete the message) received (including duplicate segments) can beimmediately acknowledged back to the peer wireless protocol layer andcan be queued pending receipt of all message segments via an inboundmessage map. When the last segment to complete the message is received,the PG 116 does not immediately send an acknowledgment to the peerwireless protocol layer. Instead, the message segments can be assembledinto a complete message, which can be forwarded to an appropriate BES122 via an MR 124. When the BES 122 successfully receives the messageand acknowledges the same to the PG 116 via MR 124, then the PG 116 canacknowledge the last segment received thus completing the acknowledgmentof the entire message. An inbound message map can manage a separateinbound message map for each unique link station ID of a sender.

[0161] 4. Message Segment Duplication Detection

[0162] When a message segment has been received for a segmented message,the PG 116 can check to make sure the message segment has not beenalready received (i.e., a duplicate message segment). If the messagesegment is a duplicate, the segment can be acknowledged to the peerwireless protocol layer, discarded and conditionally logged.

[0163] 5. Message Duplication Detection

[0164] When all message segments have been received for a message, thesegments can be assembled into a complete message. If the message ID ofthe assembled message has been already received (duplicate message),then the message can be acknowledged to a corresponding peer wirelessprotocol layer, discarded and conditionally logged. Each PG 116 can keeptrack of the last n message IDs received for each unique link stationID.

[0165] 6. Message Pacing/Message Retries/Message Time Outs

[0166] Any message that is bound for a client device 112 can besegmented into a number of segments greater than a segmented pacingthreshold and can be sent at a pacing interval. The threshold andinterval can be configurable prior to a gateway protocol startup. EachPG 116 can automatically retransmit any message segment transmitted overthe network that is not acknowledged by a corresponding peer wirelessprotocol layer within a configurable amount of time. The PG 116 canretry a configured number of times before notifying a BES 122 that themessage could not be delivered to a client application.

[0167] 7. Forwarding of Ack/Nack Messages

[0168] When a message segment is transmitted over the network 212, eachPG 116 can retain knowledge of all outstanding message segments pendingacknowledgment (message segments that have not been acknowledged by thepeer wireless protocol layer) via a pending acknowledgment map. Thepending acknowledgment map can maintain information pertaining tomessage segments that have been successfully transmitted and are pendingacknowledgment from the peer wireless protocol layer. If anacknowledgment (positive or negative) is received for a message segmentthat is not pending acknowledgment, the segment can be discarded andconditionally logged.

[0169] When all message segments have been positively acknowledged bythe peer wireless protocol layer, the PG 116 can sen, as shown in step 5of FIG. 7, an ACK control message to the BES 122 via MR 124 (providedthat the BES 122 has requested such notification) to indicate themessage has been successfully delivered to the client application. Ifthe number of transmission attempts for the message segment exceeds aconfigurable number of retry attempts, the PG 116 can send an NACKcontrol message to the BES 122 to indicate that the message could not bedelivered to the client application.

[0170] B. Message Router MR Operation and Services

[0171] Each MR 124 can communicate with the PGs 116 and BESs 122. Uponstart up, the MR 124 can use the registration services provided by theintelligent messaging network server SDK to register the MR 124 itselfwith the intelligent messaging network by adding an entry to theRegisteredServers table in the MR database 128. The MR 124 can also usethe registration services to enumerate the list of all the PGs 116 andBESs 122 that are registered with the intelligent messaging network.Using the IP address and listener port or socket for each PG 116, the MR124 can establish and manage a TCP/IP connection with each PG 116contained in the enumerated list. When an MR 124 connects to a PG 116,the PG 116 can add the MR 124 to its Server Connections cache and canbegin to start forwarding messages to the MR 124. Based on the IPaddress and listener port for each BES 122, the MR 124 can alsoestablish and manage a TCP/IP connection with each BES 122 contained inthe enumerated list. See FIG. 1C. When a MR 124 connects to a BES 122,the BES 122 can also add the MR 124 to its Server Connections cache andcan begin to start forwarding messages to the MR 124.

[0172] Each MR 124 can also use the registration services provided bythe intelligent messaging network server SDK to de-register itself fromthe intelligent messaging network by removing its entry from theRegisteredServers table in the MR database 128. The MR 124 can close theTCP/IP connection with each PG 116. Each PG 116 can also remove the MR124 from its Server Connections cache and can immediately stopforwarding messages to the terminating MR 124. Then, the MR 124 canclean up any previously allocated resources and can terminate.

[0173]FIG. 1C depicts an exemplary embodiment illustrating messagingrouting according to the present invention. FIG. 1C illustrates a clientuser 102 using a client device 112 can attempt to communicate viawireless network 108 and network 114 to resources coupled to PG 116. Asshown, BESs 122 a. 122 b and 122 c can have already registered upon bootwith MRDB 128 of MR 124. Advantageously, according to the presentinvention, routing can be based on content instead of address.Registration or discovery can include a providing server identifier(ID), a service type, and a message type supported by the particular BES122. MR 124 can load into the cache of MR 124, the registrationinformation about BESs 122.

[0174] MRs 124 and BESs 122 can communicate via a TCP/IP connection. Asshown, BES 122 a can be registered for service type 7 and message type5. BES 122 b can be registered for service type 7 and all message typesas illustrated by an asterisk (*) wildcard character. Each BES can havea unique server ID and service type combination. The only server ID thatcan be shared is 0 (zero).

[0175] The client device 112 can communicate with PG 116 and can send amessage including a unique message key. The unique message key caninclude, in an exemplary embodiment, a server identifier (ID), a servicetype and a message type, as shown. The PG 116 can provide the MR 124 themessage over network 118 b.

[0176] PG 116, in an exemplary embodiment, can route to a least recentlyused MR 124, providing a round-robin load balancing function. In anexemplary embodiment, redundancy can be provided by using, e.g.,multiple PGs 116 and multiple MRs 124. Similarly, when an MR 124 has amessage to route to a PG, in the case of an alert or a response, the MR124 can similarly use a round-robin load balancing method to route themessage to a least recently used PG 116 supporting the protocol of theclient device 112 associated with the message.

[0177] Also, MR 124 can route a message received from the PG 116, to aBES 122 or HBES 132. MR 124 can route the message, in an exemplaryembodiment, according to a set of semantic rules. In an exemplaryembodiment, the message can be routed to the BES 122 which mostspecifically corresponds to the contents of the message key. In anexemplary embodiment if more than one BES 122 corresponds specificallyto the message key, the least recently used BES 122 can be used bychecking a time stamp identifying the last access to the BES 122.

[0178] As an illustrative example, suppose client device 112 sends amessage containing a message key {server ID=0; service type=7; andmessage type=5} to a BES 122. In the exemplary illustration, PG 116would forward the message to the least recently used MR 124. MR 124could look at the message key {0, 7, 5} to determine how to route themessage. Based on the example registrations described above for BES 122a {0, 7, 5}; BES 122 b {0, 7, *}; and BES 122 c {1, 7, *}, MR 124 couldroute the message to BES 122 a since the BES 122 a most specificallycorresponded to the message key by having the exact service type andmessage type as the message key. It is important to note that BES 122 bwith a wild card asterisk for supported message type could also supportthe message if BES 122 a was not available. The semantic rules could usethe BES 122 b as an alternative routing destination, if BES 122 c isunavailable.

[0179] For purposes of sending follow-on messages to a particular BES122, in an exemplary embodiment, a specific server ID can be placed in amessage. In an exemplary embodiment, only one BES 122 will have aspecific combination of server ID and service type.

[0180] In addition to the common services that all intelligent messagingnetwork servers support, the MRs 124 are responsible for supporting thefollowing specific services:

[0181] 1. MR Message Authentication Service

[0182] The MR 124 can be responsible for determining that the sender ofa message is an authorized customer of the intelligent messagingnetwork. When the source of a message is a client device 112, the MR 124can use the device's source address (e.g., IP address or Mobitex MANnumber) of the client device 112 as the means of identifying authorizedaccess.

[0183] When each MR 124 receives a client message, it can check thedevice address against a local cache of authorized devices 112. If thesource address is not found locally, the MR 124 can then check the MR DB128. If the device address is an authorized client device 112, in anexemplary embodiment, and the customer has permission rights to therequested service type, and the requested service type is not in use bythe customer's account with a different source address, the MR 124 cancache the device address, customer identifier, and requested servicetype to ensure fast authentication of additional messages from the samesource. Then, the message can be considered authentic and can beforwarded to the proper BES 122. Each MR 124 also can pass the customeridentifier to the BES 122 to use as a key to search for customerspecific information.

[0184] In order to support dial-up access, in an exemplary embodiment,message authentication based on the device's source address is not used,because during a dial-up access, the source address that can be seen byan MR 124 is the IP Address of the ISP provider. Each subscriber thatdesires wire-line access can have a User ID and Password, which can beselected by the subscriber at the time they subscribe to a service, andcan be saved as part of the MR DB 128.

[0185] Each MR 124 can initially follow the same procedure toauthenticate a dial-up message as it does when authenticating a wirelessmessage. However, in case a message is received from a dial-upconnection, the MR 124 can issue an authentication challenge to themessage source. On receiving the challenge, the client application canprompt the user 102 to enter the user ID and password of the user 102,which can be forwarded (encrypted) to the MR 124 as an authenticationrequest and can proceed with authentication process.

[0186] Once a message source has been authenticated, the MR 124 cancheck the service type and source address of subsequent messages againstits authentication cache and can allow/disallow the message asappropriate. Preferably, in an exemplary embodiment, the MR 124 does notkeep the cached mapping between a source address and valid customerindefinitely. A configurable timeout period may be specified, afterwhich cached entries can be removed. The timeout interval can be thelength of time that has passed between successive messages from a cachedclient device 112. When a client device 112 times out due to inactivity,the MR 124 can remove it from its cache. For dial-up devices, the MR 124can also decrement a device's authentication count within theintelligent messaging network MR database 128. The authentication countcan indicate how many other MRs 124 have heard from the client device112. When a dial-up device's authentication count drops to zero, thedevice address can be removed from the MR DB 128.

[0187] 2. MR client Message Routing Service

[0188] According to an exemplary embodiment of the invention, there canbe several ways in which an MR 124 can route a client message to a BES122, including, e.g.,:

[0189] Indirect Routing—via an indirect routing table that can mapmessage keys (service type and message ID) to a registered BES 122 thatsupports the message key; and

[0190] Direct Routing—via targeting messages at a specific BES 122.

[0191] The form of routing can be determined based on the contents of anintelligent messaging message header. The intelligent messaging messageheader or message key can be pre-fixed to every application message.

[0192] The intelligent messaging message header can contain thefollowing fields, e.g.,:

[0193] a 1-byte Server ID that can identify a specific server of thegiven service type. The value 0 can be reserved to indicate thatindirect routing is desired. A non-zero value can indicate that themessage is directed at a specific BES 122;

[0194] a 12-bit Service Type Identifier, which can be used by bothindirect and direct routing, can identify the type of service (e.g.,MarketClip, FX, etc.) associated with the messages; and

[0195] a 12-bit Message Type Identifier that can uniquely identify themessage within the context of the specified service type required fordirect routing.

[0196] a. Indirect Routing

[0197] When an MR 124 receives an incoming message from a clientapplication, it can check the Server ID field contained in theintelligent messaging message header portion of the message. If theServer ID field of the intelligent messaging message header is zero, theMR 124 can route the message to the proper BES 122 by consulting arouting table that can map message keys (Service Type and Message ID) tothe IP address of one or more connected BESs 122 a-c as described abovewith reference to FIG. 1C.

[0198] During server registration, all BESs 122 can be required toregister a list of supported message keys. To minimize the number ofentries that are made in the routing table, if a given BES 122 supportsthe majority of messages for a specific Service Type, it need onlyregister a single root message key including only the Service Type. Thesmall subset of service messages not supported by that BES 122 would beregistered as individual message keys by a different BES 122 of the sameService Type. The MR 124 can route messages based on the most specifickey value (Service Type, Server ID, and Message ID) found in the table.If no specific mapping is found, the MR 124 can use the Service Typeportion of the key to look for root message entries. If the MR 124locates more than one BES 122 that satisfies the message key match, itcan use a round-robin scheduling procedure to pick which target BES 122to route to. For example, the timestamp of last access of the BES can beconsulted to determine a least recently used BES 122.

[0199] Consider, e.g., two third party services, MarketClip and FX,Reulers(t news service solutions for real-time reporting on equities andforeign exchanges, with messages for each application supported by acorresponding BES 122. Under the configuration of the invention, eachapplication BES 122 could only have to register its root service type(e.g., MktMon or FX) in order for its messages or responses for clientdevices 112 to be routed correctly by the MR 124. Suppose that two BESs122 currently support news requests independently of one another (i.e.there is no common news BES 122 that both of them use), but a separatenews BES 122 can be created to handle ALL news requests. Ideally, no newsoftware should be sent to service providers so that all future newsmessages (for either application) are tagged to go to the new newsserver. Rather, the new news BES 122, upon registration, can add thespecific news message keys previously handled by the MarketClip and FXBESs 122 to the MRs 124 message routing table.

[0200] It should be noted that the original BESs 122 do not need tochange because the news BES 122 message keys can contain the servicetypes and message IDs specific to the two applications. Each MR 124 cando its primary routing based on the more specific table entries, thesame news messages that would have formerly been routed to the two BESs122, could get routed to the new news BES 122. Thus, the BESs 122 can bedesigned around specific services, rather than a suite of services thatcomprise an application, some of which may be common to otherapplications. Under this arrangement, overall response performance canimprove as specific services are assigned to their own BES 122. This isbecause a client application not using a given service does not have towait, while the BES 122 is accessing process requests for a differentservice.

[0201] b. Direct Routing

[0202] BESs 122 that can maintain state information about a particularclient device 112 can often require direct routing. For a client toensure that a message reaches a specific BES 122, the intelligentmessaging network message header portion of the message can contain anon-zero value in the Server ID field. When an MR 124 sees a non-zerovalue in the Server ID field, it can route the message to the proper BES122 by consulting a routing table that maps server keys {Service Type,Message ID, Server ID} to the IP address of a connected BES 122.

[0203] Specifying a Server ID alone can be not sufficient to ensure thatthe message is delivered to the proper BES 122. Even when using directrouting, a BES 122 can register the service types and message IDs it canhandle; and the service type/message ID of a direct route message canmatch those types registered by the BES 122 with the specified ServerID. Management of BES 122 IDs can be the responsibility of theapplication. If an application runs more than one BES 122 with the sameServer ID, then messages with that Server ID can be routed to the BES122 whose message routing table can contain the most specific match withthe messages service type and Message ID. If two BESs 122 can map thesame Server ID, Service Type, and Message ID, then, as in indirectrouting, the MR 124 can use round robin scheduling to pick a target BES122.

[0204] A BES 122 may use both direct and indirect routing on an asneeded basis. To illustrate this, consider a BES 122 that for the mostpart is stateless, but has one or two logical operations that canrequire several targeted client/server messages to complete. If the BES122 can initiate an operation that can require a targeted response, itcan place its Server ID in the intelligent messaging network messageheader portion of the message it sends to the client application. Whenthe client application responds, it uses the same Server ID in theresponse message to assure that the response is sent to the originalServer. All other “stateless” messages can be sent with a Server ID of0, so that they can be indirectly routed.

[0205] 3. MR Back-End Server BES Message Routing Service

[0206] BES 122 messages sent to a client application can pass throughthe MR 124. Each MR 124 can decide which PG 116 to which to forward themessage. The MR 124 can choose the proper PG 116 based on, e.g., thecommunications type (e.g., CDPD, Mobitex, ISP Dialup, etc.) used by asubscriber's service provider. The mapping of communication type toclient device address can be maintained by the MR 124 based on fixedentries in the MR DB 128 that can map source address of a client device112 or used ID and password to a specific communication type. Each PG116 can also indicate the communication type of the PG 116 during theserver registration process. If a PG 116 could not deliver a message tothe client application, the PG 116 can send a network controlnon-acknowledgement (NACK) message to the BES 122 that originated themessage, indicating that the message could not be delivered.

[0207] 4. Send via clientDeviceInfo

[0208] When a BES 122 sends a message to a client application inresponse to a received request message, the client device address(referred to, as its clientDeviceInfo), which is a part of the receivedrequest message, can be known to the BES 122. In response, the BES 122can provide the clientDevicelnfo as part of the AIMSvrPacket sent to theMR 124. Consequently, the MR 124 can then simply pass this informationto the appropriate PG 116, which can then send the message to thatclient device 112 address.

[0209] 5. Send via CustomerID

[0210] At times, a BES 122 may need to asynchronously send a message toa subscriber (e.g. MarketClip Alert). Since this message is not inresponse to an incoming client message, the clientDevicelnfo may not bereadily available to the BES 122. Rather than forcing the BES 122 tokeep a mapping between client identifiers and their LinkStationIDs, aBES 122 may send a message to a client based solely on the customer ID.In this case, the AIMSvrPacket sent to a MR 124 contains a NULLLinkStationID and a valid client ID. The receiving MR 124 can searchit's authenticated device cache for an active device associated with thespecified client ID and then can use the device's LinkStationID toforward the message to an appropriate PG 116.

[0211] C. Back-End Server BES Operation and Services

[0212] A BES 122 is an application specific server that can implementlogic to process messages specific for that type of server. For example,an FX BES 122 can handle requests related to foreign exchange functions.A BES 122 can communicate directly with one or more MR 124s. Typically,BESs 122 can run behind the firewall 120. However, the intelligentmessaging network architecture cannot preclude BESs 122 from runningoutside the firewall 120.

[0213] Excluding the application logic, which may be complex, thedevelopment effort to implement a BES 122 can be relativelystraightforward. The intelligent messaging network Server SDK canencapsulate those functions that are common to all BES 122s, therebyinsulating developers from, e.g., details of transport control,compression, registering and de-registering with the MR DB 128. Similarto other servers, the BESs 122 can use the registration servicesprovided by the intelligent messaging network server SDK to registerthemselves with the intelligent messaging network by adding an entry tothe RegisteredServers table in the MR DB 128. Each BES 122 can establisha TCP/IP connection with each registered MR 124, using a correspondingIP address. When a BES 122 connects to an MR 124, the MR 124 can add theBES 122 to its RegisteredServers cache and can begin to start forwardingmessages to the BES 122. When de-registering itself from the network,each of the BESs 122 remove its entry from the RegisteredServers tablesin the intelligent messaging network MR database 128. The BES 122 cannotify each MR 124 of its impending shutdown. This can allow each MR 124to remove the BES 122 from its RegisteredServers cache and canimmediately stop forwarding messages to the terminating BES 122.

[0214] In addition to the common services, the BESs 122 can beresponsible for supporting the following specific functions:

[0215] 1. Application Protocol Aware Service

[0216] From the perspective of the BES 122, the BES 122 can directlywith a client application. In reality, however, a BES 122 cancommunicate with one or more MRs 124. In the intelligent messagingnetwork architecture, only the BESs 122 can have knowledge of theapplication content required to communicate with a client application.

[0217] 2. Extended Intelligent Messaging Network Compression

[0218] In the exemplary embodiment, intelligent messaging network canprovide an Adaptive-Huffman base compression service. The intelligentmessaging network architecture can provide the necessary hooks to enable3^(rd) party OEM compression mechanisms. If a BES 122 has specificcompression requirements for its application data that are not addressedby intelligent messaging network supplied compression services, (i.e.Adaptive-Huffman); the BES 122 can be responsible for providing thecompression mechanism.

[0219] 3. Security Services

[0220] The architecture can provide the necessary hooks to enable 3^(rd)party OEM security mechanisms. If a BES 122 has specific securityrequirements for its application data, the BES 122 can be responsiblefor providing the security mechanism.

[0221] 4. Forwarding of Ack/Nack Messages

[0222] When a client message is delivered to the BES 122, the BES 122can send a network control acknowledgement (ACK) message to a PG 116that originally received the message. When the PG 116 receives thenetwork control ACK message from the BES 122, it can send a transportlevel ACK message to the client device's peer wireless protocol layerindicating that the message was delivered successfully to the BES 122.

[0223] III Intelligent Messaging Network MR Database

[0224] In an exemplary embodiment of the present invention, anintelligent messaging network database can use an AIM Database availablefrom Aether Systems of Owings Mills, Md., U.S.A. which, can maintain acommon pool of information between intelligent messaging networkservers. This information, which is independent of any specificmessaging application, can be stored and accessed from a SQL databaseknown as, e.g., the MR DB 128, or the BES DB 126. In an exemplaryembodiment, the MR DB 128 can be shared by all intelligent messagingnetwork servers 116, 122, and 124. The following sections describe thetables that comprise the intelligent messaging network MR database 128schema. It will be apparent to those skilled in the art that the schemacould also be used for another database, such as, e.g., BES DB 126.

[0225] 1.1 Schema

[0226] 1.1.1 ServiceTypes Table

[0227] The ServiceTypes table is a list of all the service typessupported by the intelligent messaging network. ServiceTypes TableColumn Name Type Description ServiceName varchar[30] Service Name TypeIDint ID of the Service AllowMultiAccess bit True if service allowsmultiple device access from a single user, false if only allows singledevice access from single user concurrently

[0228] 1.1.2 RegisteredServers Table

[0229] The RegisteredServers table is used during the connection processand keeps track of the location and type of all Servers currentlyrunning on the Network. Access to this table is through the Server SDK.RegisteredServers Table Column Name Type Description DbID long Unique DBID used for cross referencing ServiceName varchar Server Name [30] Classint Server Class e.g. FES (PG), BES, MR 124 etc SubClass int ServerSubclass e.g. CDPD, Mobitex, etc DeathCount int The number of timesconnecting Servers have failed to connect to the Server

[0230] 1.1.3 ServerMsgMap Table

[0231] The ServerMsgMap is accessed during Server Registration, MR 124Start-UP and client Message Routing. This table maps a running Server tothe set of Message's that should be routed to that Server. Access tothis table is through Intelligent messaging network Server SDK.ServerMsgMap Table Column Name Type Description ServerDBID long Crossreference to DBID column in RegisteredServer Table ServiceType int Typeof Service message handled by this Server MessageID int MessageIdentifier of message handled by this Server ServerID byte Optional IDused for Server-Specific Message Routing

[0232] 1.1.4 AuthorizedUsers Table

[0233] The AuthorizedUsers table is accessed during Messageauthentication. The table contains a list of UserIDs/Passwords withauthorized access to the intelligent messaging network Network. Accessto this table is through the Server SDK. AuthorizedUsers Table ColumnName Type Description UserID varchar[25] Identifier chosen by thecustomer e.g. (rudy, RudyB etc). This is the login ID for ISP dial-upservice. Password varchar[25] Customer Password AccountNo char[8]Customer Account Identifier CustomerID long Unique CustomerID used forcross referencing

[0234] 1.1.5 AuthorizedDevices Table

[0235] The AuthorizedDevices table is accessed during messageauthentication. This table contains a list of device addresses withauthorized access to the intelligent messaging network Network. Entriesmay be permanent (a Mobile client Device) or temporary (a Wire-linedevice). Access to this table is through the intelligent messagingnetwork Server. AuthorizedDevices Table Column Name Type DescriptionDevAddress varchar[25] Mobile client device address (IP, MAN, etc)Wireline bit 0 = Mobile client, 1 Wire-line CommType int CommunicationType (CDPD, Mobitex, CDMA, etc) of the client device Authentication intNo. of MRs 124 currently aware of this Count device AccessFlag int Usedto block access for devices reported missing or stolen CustomerID longCross reference to Customer ID in AuthenticatedUsers table Token longToken used for security with wireline devices

[0236] 1.1.6 UserRights Table

[0237] The UserRights table is accessed during message authentication.This table contains the service types an authorized user can access.Access to this table is through the Server SDK. UserRights Table ColumnName Type Description CustomerID long Cross reference to CustomerID inAuthenticatedUsers table. ServiceType int Service Type the Customer isauthorized to use. Cross reference to TypeID in ServiceType table.

[0238] 1.1.7 ActiveUsers Table

[0239] The ActiveUsers table is accessed during message authentication.This table contains the list of active customer IDs and the servicesthey are using with a count of MRs 124 that have authenticated theaccount for the service in use. The purpose of the table is to detectand prevent multiple devices from accessing a service with same customerID when the AllowMultiAccess bit is “false.” Also, the table containsthe LinkStationType and LinkStationID used by the customer so the MRs124 can support NULL LinkStationID from the BES 122. Access to thistable can be through the intelligent messaging network server.ActiveUsers Table Column Name Type Description CustomerID long Crossreference to CustomerID in AuthenticatedUsers table. ServiceType intService type in use by Account No MRCount byte Number of MRs 124 thathave authenticated the account for the service in use CommType smallintCommunication Type (CDPD, Mobitex, etc) of the client deviceLinkStationID varchar[25] IP/Port or Mobitex Address

[0240] 1.1.8 CommTypes Table

[0241] The CommTypes table is a list of all communication Protocolssupported by the intelligent messaging network. CommTypes Table ColumnName Type Description CommName varchar[25] Name of the communicationProtocol TypeID smallint Communication Type ID

[0242] 1.2 Stored SQL Procedures

[0243] SQL procedures are used to manage the database. The following isa list of definitions commonly used as parameters in the stored SQLprocedures.

[0244] CustomerID—The customer's unique identifier.

[0245] UserId—The user Id is used to authenticate ISP dial-up access.

[0246] Password—The password is used to authenticate dial-up access.

[0247] AccountNo—The account number can be both alpha and/or numeric andis for customer service purposes.

[0248] ServiceType—The service type the customer is provisioned toaccess. For example, MarketClip, MarketTrader, etc.

[0249] DeviceAddress—For CDPD devices, this is an IP address in dotnotation. For Mobitex, this is a MAN number.

[0250] CommType—The type of Network Protocol the client device is usingto access the intelligent messaging network Network. For example, CDPD,Mobitex, CDMA.

[0251] DeviceType—The type of access to the intelligent messagingnetwork Network, either wireless or wireline.

[0252] NotifyAMR—True to notify all MRs 124 and false to not notify.

[0253] ReturnCode—The return code from the stored procedure.

[0254] 1.2.1 NewCustomer

[0255] This stored SQL procedure allows customer service to enter a newcustomer using a wireless CDPD device to the database. User Id andPassword are entered as NULL.

[0256] Input:

[0257] UserID (varchar[25])

[0258] Password (varchar[25])

[0259] DeviceAddress (varchar[25])

[0260] AccountNo (char[8])

[0261] ServiceType (int)

[0262] Output:

[0263] CustomerID (int)

[0264] ReturnCode (int)—0=Success, 1=Duplicate User ID, 2=Duplicatedevice address.

[0265] 1.2.2 DeleteCustomer

[0266] This stored SQL procedure allows customer service to delete acustomer from the database. This procedure also deletes any devices usedby the customer and services provisioned for the customer.

[0267] Input:

[0268] CustomerID (int)

[0269] Output:

[0270] ReturnCode (int)—0=Success, 1=Invalid customer id.

[0271] 1.2.3 AddUser

[0272] This stored SQL procedure allows customer service to add a userid and password to the database.

[0273] Input:

[0274] UserId (varchar[25])

[0275] Password (varchar[25])

[0276] AccountNo (char[8])

[0277] Output:

[0278] CustomerID (int)

[0279] ReturnCode (int)—0=Success, 1=Duplicate user id.

[0280] 1.2.4 DeleteUser

[0281] This stored SQL procedure allows customer service to delete acustomer from the database. This procedure also deletes any devices usedby the customer and services provisioned for the customer.

[0282] Input:

[0283] CustomerID (int)

[0284] Output:

[0285] ReturnCode (int)—0=Success, 1=Invalid customer id.

[0286] 1.2.5 Change Password

[0287] This stored SQL procedure allows customer service to change auser's password in the database.

[0288] Input:

[0289] UserID (varchar[25])

[0290] Password (varchar[25])

[0291] Output:

[0292] ReturnCode (int)—0=Success, 1=Invalid UserID

[0293] 1.2.6 AddUserRight

[0294] This stored SQL procedure allows customer service to add a useraccess right to a customer defined in the database.

[0295] Input:

[0296] CustomerID (int)

[0297] ServiceType (int)

[0298] Output:

[0299] ReturnCode (int)—0=Success, 1=Invalid customer id, 2=Duplicateentry

[0300] 1.2.7 DeleteUserRight

[0301] This stored SQL procedure allows customer service to delete auser access right from a customer defined in the database.

[0302] Input:

[0303] CustomerID (int)

[0304] ServiceType (int)

[0305] Output:

[0306] ReturnCode (int)—0=Success, 1=Invalid customer id, 2=Invalid userright for the customer.

[0307] 1.2.8 AddDevice

[0308] This stored SQL procedure allows customer service to associate adevice address to a defined customer in the database.

[0309] Input:

[0310] DeviceAddress (varchar[25])

[0311] Wireline (bit)—0=client, 1=wireline.

[0312] CommType (smallint)—1=CDPD, 2=Mobitex, 3=ISP Dial up CustomerID(int)

[0313] Token (int)

[0314] Output:

[0315] ReturnCode (int)—0=Success, 1=Bad parameter, 2=Duplicate deviceaddress, 3=invalid customer id, 4=Customer already has device address.

[0316] 1.2.9 DeleteDevice

[0317] This stored SQL procedure allows customer service to delete adevice address from a defined customer in the database.

[0318] Input:

[0319] DeviceAddress (varchar[25])

[0320] Output:

[0321] ReturnCode (int)—0=Success, 1=Device address not found

[0322] 1.2.10 DeleteDeviceByCustID

[0323] This stored SQL procedure allows customer service to disassociateby deletion of ALL device addresses from a defined customer in thedatabase.

[0324] Input:

[0325] CustomerID (int)

[0326] Output:

[0327] ReturnCode (int)—0=Success, 1=No device address(es) to delete.

[0328] 1.2.11 SuspendUser

[0329] This stored SQL procedure allows customer service to suspend auser and all the user's device address' access to the intelligentmessaging network and notify all MRs 124 to remove the device addressfrom it's local cache. This mechanism is used when a customer reports alost or stolen client device.

[0330] Input:

[0331] CustomerID (int)

[0332] Output:

[0333] ReturnCode (int)—0=Success

[0334] 1.2.12 ReactivateUser

[0335] This stored SQL procedure allows customer service to reactivate auser and all the user's device address' access to the intelligentmessaging network.

[0336] Input:

[0337] CustomerID (int)

[0338] Output:

[0339] ReturnCode (int)—0=Success.

[0340] 1.2.13 SuspendDevice

[0341] This stored SQL procedure allows customer service to suspend adevice address' access to the intelligent messaging network and notifyall MRs 124 to remove the device address from it's local cache.

[0342] Input:

[0343] DeviceAddress (varchar[25])

[0344] NotifyAMR 24 (bit)—T rue to suspend the device address from allMRs 124 memory, false not to.

[0345] Output:

[0346] ReturnCode (int)—0=Success, 1=Error creating Server Manager,2=Error calling Server Manager.

[0347] 1.2.14 ReactivateDevice

[0348] This stored SQL procedure allows customer service to reactivate adevice address' access to the intelligent messaging network.

[0349] Input:

[0350] DeviceAddress (varchar[25])

[0351] Output:

[0352] ReturnCode (int)—0=Success.

[0353] 1.2.15 GetCustomerID

[0354] This stored SQL procedure allows customer service to get thecustomer identifier associated with a device address.

[0355] Input:

[0356] DeviceAddress (varchar[25])

[0357] Output:

[0358] CustomerID (int)

[0359] ReturnCode (int)—0=Success, 1=Device address not found.

[0360] IV HTTP Proxy Back End Server

[0361] Most industry standard browsers support the ability to beconfigured to access the Internet via a proxy server instead ofcommunicating directly with an HTTP Web Server. The Intelligentmessaging network HTTP Proxy Back End Server 132 is responsible forhandling incoming HTTP requests, sending the request over the Internetto the target Web HTTP Server, and transmitting the response back to theclient device. The Intelligent messaging network HTTP Proxy Back EndServer 132 supports various versions of the HTTP protocol specification.The HTTP Proxy Back End Server 132 is also responsible for communicatingwith a target HTTP Web Server. In order to handle each inbound HTTPrequest, the HTTP Proxy Back End Server 132 creates and manages a TCP/IPsocket connection to the target Web HTTP Server. When the HTTP ProxyBack End Server 132 receives the response from the Web HTTP Server, itcreates an HTTP response message and formats it for transmission back tothe client application running on a client device.

[0362] V. HTTP Redirector

[0363] Browsers 104 can typically communicate directly to an HTTP WebServer via TCP/IP. TCP/IP, however, is a chatty LAN protocol requiringsignificant overhead that is not a cost effective way for browsing theInternet wirelessly. According to one embodiment of the invention, anHTTP Redirector 106 can intercept raw HTTP requests from the browser 104and can redirect the request over the intelligent messaging network forfulfillment by an HTTP Proxy Back End Server 132. When the HTTPRedirector receives a response from the HTTP Proxy Back End Server 132,it can simply pass the response to the browser 104 to process.

[0364]FIG. 2 illustrates a block diagram 200 of an exemplary embodimentof the present invention. Block diagram 200 illustrates an HTTPRedirector 106 interacting with the browser 104 and intelligentmessaging network network. The HTTP Redirector 106 can act as a “clientside” proxy server allowing it to intercept Web browser HTTP requests.When communicating over the wireless network, the HTTP Redirector 106can take advantage of the optimized wireless protocol and compressionservices offered by the Intelligent messaging network and the protocolof the present invention. This results in significant byte savings whensending HTTP requests and receiving HTTP responses over a wirelessnetwork. In the exemplary embodiment, the HTTP Redirector can supportbrowsers 104 such as, e.g., Microsoft's Internet Explorer 4.0 andNetscape's Communicator 4.5 browsers on the Windows 95, 98, NT, 2000 andWindows CE platforms.

[0365] As mentioned above, browsing the Internet using a standardversion of a conventional browser 104 is not ideal in a wirelessenvironment. Standard versions of browsers 104 send HTTP requests overTCP/IP, which is a chatty LAN protocol. TCP/IP is not cost effective interms of bandwidth usage in a wireless environment. Furthermore, astandard version of browser 104 can require an IP based network andconventionally does not work with non-IP based wireless networks such asMobitex. The redirector 106 can address these issues and can provide amethod of using a standard Web browser 104 in a wireless network.

[0366] Referring to FIG. 2, in an exemplary embodiment, browser 104 of aclient device 112 can typically allow access to resources such as, e.g.,a destination Web server 210, such as an Internet server 142 a on anetwork 202, such as, e.g., the global Internet, through a Proxy IP/port204 instead of communicating directly with the destination Web server210. In the environment of the present invention, the Proxy IP/port 204can fulfill a request on behalf of the client device 112 to thedestination Web server 210. The redirector 106 can act as a“client-side” proxy. The HTTP Redirector 106 can sit on top of standardmobile libraries 208 provided by the intelligent messaging network.These mobile libraries 208 can be optimized for the specific wirelessprotocol supported by the specific client device 112 a-c.

[0367] The HTTP Redirector 106 can intercept all requests from browser104. The raw HTTP request can then be packaged into an intelligentmessaging network message and transmitted through the intelligentmessaging network 114 to the BES 122 a-c designed to handle HTTPrequests.

[0368] The HTTP BES 132 can forward the request to a Web server of acontent provider such as, e.g., destination web server 210, which canprovide a response. The content provider can be a third party in anexemplary embodiment. The communication to the content provider canoccur via the network 202 of FIG. 2. A network 212 depicted in FIG. 2can include the intelligent messaging network of the present invention,e.g., the underlying LAN network 118 a and b, the PGs 116, the firewall120, router 110, and the MR 124.

[0369] When the HBES 132 receives the response from the destination Webserver 210, HBES 132, or BES 122 (not shown), can package the responseinto an intelligent messaging network message and can transmit theresponse back to the requesting client device 112 via the PG 116 via theMR 124.

[0370] When the message arrives at the client device 112, it can bepassed up to the redirector 106 where the message can be unpacked fromits intelligent messaging network format into an HTTP response and canbe sent to the browser 104. The HTTP redirector 106 can maintain allconnections with the browser 104 throughout this process, so that fromthe perspective of the browser 104, the browser 104 appears to becommunicating directly to the Web server 210.

[0371] The mobile libraries 208 can be optimized for the underlyingwireless protocol. The HTTP Redirector 106 can sit on top of thelibraries 208 providing the browser 104 with the same benefits withoutany modifications to the browser 104. Since the HTTP Redirector 106packages HTTP requests and responses into intelligent messaging networkmessages, the raw payload of the messages can be compressed. Mostconventional Web traffic deals with straight text in the form of HTML,so the amount of data transmitted can be greatly reduced by usingstandard compression techniques. The compression techniques can resultin an increase in data throughput and a reduction of airtime.

[0372] In addition to compression, in an exemplary embodiment,performance can be enhanced by the fact that TCP/IP is not used over thewireless network, where the SNTL transport protocol of the presentinvention is rather used.

[0373] Turning briefly to FIG. 3, an exemplary embodiment of a networkcommunications layered architecture is depicted. FIG. 3 includes blockdiagram 300, which is described further below following the descriptionwith reference to FIG. 8A.

[0374] VI. Message Flow

[0375] The flow of any messages within the network can includeauthentication by the MR 124 via authentication challenge success,failures, client application request to BES 122, BES 122 response toclient application, and BES 122 to client application.

[0376]FIG. 4 illustrates a flow diagram 400 depicting an exemplaryembodiment of the present invention. Flow diagram 400 numericallydepicts a flow of messages that corresponds to the authenticationchallenge success flow. Flow diagram 400 numerically shows message pathsbetween a client device 112 and an MR 124 including exemplary stepslabeled by numbers 1-8, as follows:

[0377] 1. The client application can send an application request messageto the MR 124 (the PG 116 is not explicitly involved in authentication),i.e., a device authentication;

[0378] 2. The client application running on a client device may fail theauthentication of the MR 124;

[0379] There are several ways a client application running on a clientdevice can fail authentication. The MR 124 cannot find the deviceaddress in its local cache or the AuthorizedDevices table in theintelligent messaging network MR database 128. The device's securitytoken in the LinkStationID is not the same as the device's securitytoken in the intelligent messaging network MR database 128. Thesubscriber does not have user rights to the requested service.

[0380] 3. The MR 124 can send a a negative acknowledgment (NACK) messageto the client application with the appropriate error code;

[0381] 4. The client application can respond with an authenticationrequest message including an UserID, secure password, and the requestedservice type to authenticate; i.e., reauthentication;

[0382] 5. The MR 124 can check the UserID and password against theAuthorizedUsers in the MR DB 128;

[0383] If the UserID/password are valid, the MR 124 can verify that thesubscriber has rights to the requested service. If the subscriber doeshave user rights to the service, the MR 124 can add the device addressto the AuthorizedDevices table, as well as to the MR 124 local cache andcan assign a security token to the client application running on theclient device 112.

[0384] 6. The MR 124 can send an authenticated response message with asuccess value to the client application to let the client applicationknow that the client application has been authenticated; the securitytoken can also be sent to the client device 112; i.e., an indication ofsuccess;

[0385] 7. The client application can re-send the original message (step1) that caused the authentication challenge with the new security token;i.e., send request; and

[0386] 8. The MR 124 can verify the device address against theauthentication cache of the MR 124 and can forward the message to theproper BES 122 or HBES 132 (not shown).

[0387]FIG. 5 illustrates a flow diagram 500 depicting an exemplaryembodiment of the present invention. Flow diagram 400 numericallydepicts a flow of messages that can correspond to the authenticationchallenge success/failure. The diagram numerically shows message pathsbetween the client device 112 and the MR 124 including exemplary stepslabeled by numbers 1-7, as follows:

[0388] 1. Client application can send an application message to the MR124 (again, the PG 116 is not explicitly involved in authentication, inan exemplary embodiment, all client/MR 124 communications can passthrough the PG 116); i.e., device authentication;

[0389] 2. The client device 112 can fail the MRs 124 authentication;

[0390] There are several ways a device can fail authentication. Forexample, the MR 124 cannot find the device address in its local cache orthe AuthorizedDevices table in the intelligent messaging network MRdatabase 128. The security token of the client device 112 in theLinkStationID can be not the same as the device's security token in theintelligent messaging network MR database 128. The user of the clientdevice 112 can not have user rights to the requested service.

[0391] 3. The MR 124 can send a negative acknowledgment (NACK) messageto the client application with the appropriate error code;

[0392] 4. The client application can respond with an authenticationrequest including the UserID, secure password and the requested servicetype to authenticate; i.e., logon with userid and password;

[0393] 5. The MR 124 can check the UserID and password against theAuthorizedUsers in the MR DB 128; the UserID, password can be invalidand/or the user can not have rights to the requested service;

[0394] 6. The MR 124 can send an authentication response message with afailure value to the client application to let it know that theauthentication has failed; i.e., authentication failure; and

[0395] 7. The client may choose to prompt the client user 102, e.g., tore-enter the UserID and password and repeat the flow diagram 500starting from step 4; i.e., retry.

[0396]FIG. 6A illustrates a flow diagram numerically depicting a flow ofmessages that corresponds to a client application request to BES 122.The diagram numerically shows message paths between the client device112 and the MR 124 including exemplary steps labeled by numbers 1-6, asfollows:

[0397] 1. The client application that can be running on client device112 can create an application request (APP REQ) message and can pass themessage to the transport layer to transmit over the network 212;

[0398] 2. The transport layer can determine if the message needs to besegmented into multiple segments; the transport layer can transmit themessage over the network and can wait for a transport level ACK;

[0399] 3. Upon receiving the APP REQ message, the PG 116 can assemblethe message segment into a complete application message (if necessary)and can send the application message to the next available MR 124;

[0400] If no MR 124 is available, a NACK message can be generated by thePG 116 and can be sent back to the client application with theappropriate error code. Preferably, the PG 116 can not immediately senda transport ACK message back to the client application. This can be donewhen the BES 122 receives the application message and sends an ACKcontrol message back to the PG 116.

[0401] 4. The MR 124 can look up the device address and the service type(first in its local cache, then if necessary in the intelligentmessaging network MR DB 128) to see if the message is from an authorizedsource;

[0402] If the message is from an authorized source, the MR 124 canchoose the next available BES 122 that has been registered to supportthe specified service type and can then send the message to that BES122. If there are no BESs 122 registered that can support the specifiedservice type, a NACK message can be generated by the MR 124 and can besent back to the client application with the appropriate error code.

[0403] 5. Upon receiving the application message from the MR 124, theBES 122 can send an acknowledgement (ACK) control message back to the PG116 that received the application message; the BES 122 can also processthe incoming message; and

[0404] 6. Upon receiving the ACK control message from the BES 122, thePG 116 can send a transport ACK message to the client application atclient device 112; in some exemplary embodiments, sending ACK messagescan be optional.

[0405]FIG. 6B depicts an exemplary embodiment of a message flow diagram602 illustrating transmission of a multi-segment message from a clientdevice 112 to a BES 122 according to the present invention. Flow diagram602 can begin with step 604.

[0406] In step 604, the simple network transport layer (SNTL)application can segment the message into multiple segments, canencapsulate the segments with an SNTL segment header 1000, and cantransmit the message initially to PG 116. An exemplary embodiment of amessage header 1000 is illustrated below with reference to FIG. 10. Aswill be apparent to those skilled in the relevant art, due to a high biterror rate in wireless communication links, it can be expected that notall transmissions to PG 116 will be received from the client device 112.From step 604, the flow diagram can continue with step 606.

[0407] In step 606, the PG 116 can send to client device 112 anacknowledgement (ACK) of receipt of the transmitted messages at the PG116. As shown, in the exemplary embodiment, receipt of only segment 1 isacknowledged. Receipt of segment 2 is not acknowledged. From step 606,the flow diagram 602 can continue with step 608.

[0408] In step 608, in an exemplary embodiment, client device 112 canautomatically retry, or retransmit segment 2 of the message to the PG116, since acknowledgement was not received for segment 2 in step 604.User datagram protocol (UDP) is an efficient communication protocol,however it is unreliable, lacking provision to segment messages andretransmit unacknowledged messages. In the exemplary embodiment, thepeer protocols of the SNTL layers on the client device 112 and PG 116can work in coordination with UDP to provide highly optimized andreliable wireless communication while using efficient connectionless(i.e., unlike TCP) UDP communication. In an exemplary embodiment, theSNTL layers can provide other useful transport functions such as, e.g.,pacing, congestion control and other functionality without requiring anentire TCP transport stack. The SNTL layer can include, in an exemplaryembodiment, a 4 bytes wide header. The header may be 6 bytes wide formulti-segment messages, as discussed with reference to FIG.10. From step608, flow diagram 602 can continue with step 610.

[0409] In step 610, PG 116 can transmit the complete multi-segmentmessage to MR 124. From step 610, flow diagram 602 can continue withstep 612.

[0410] In step 612, MR 124 can route the message to BES 122 as discussedabove with reference to FIG. 1C. From step 612, flow diagram 602 cancontinue with step 614.

[0411] In step 614, BES 122 can send an acknowledgement of receipt ofthe multi-segment message to MR 124. From step 614, flow diagram 602 cancontinue with step 616.

[0412] In step 616, MR 124 can send acknowledgement of receipt of themulti-segment message at the BES 122 on to PG 116. From step 616, flowdiagram 602 can continue with step 618.

[0413] In step 618, PG 116 can send acknowledgement of receipt of themulti-segment message at the BES 122 on to client device 112. PG 116 canalso send acknowledgment of receipt of segment 2 of the message as well.In one exemplary embodiment acknowledgment of receipt of the secondsegment can occur following step 606. From step 618, flow diagram 602can immediately complete.

[0414]FIG. 7A illustrates a flow diagram 700 of an exemplary embodimentof the present invention. Flow diagram 700 numerically depicts a flow ofmessages that corresponds to a response from BES 122 to a request of theclient application, illustrated and described further above withreference to FIG. 6A. Flow diagram 700 numerically shows message pathsbeginning from the BES 122, through the MR 124 and PG 116 to clientdevice 112 including exemplary steps labeled by numbers 1-5, as follows:

[0415] 1. A BES 122 can respond to a client application request asillustrated in flow diagram 600; the BES 122 can pass the responsemessage (REQ RESP), message flags, customer ID and LinkStationID (cachedfrom the previous incoming request) in flow diagram 700, which canrepresent a second or so-called “send” call;

[0416] Message flags can specify whether to compress and/or encrypt themessage and whether the BES 122 requires an ACK message when the PG 116has successfully delivered the application message to the clientapplication running on client device 112. The BES 122 can send theapplication message to the next available MR 124. If no MR 124 isavailable, then a false can be returned from the send.

[0417] 2. The MR 124 can use the LinkStationID to determine theassociated communication type (e.g.,CDPD, Mobitex, etc.) and can sendthe message to the next available PG 116 of the correct communicationtype;

[0418] 3. The PG 116 can segment the application message (if necessary)and can transmit the application message over the network;

[0419] 4. The transport layer can receive the message segment and canassemble the message segment into a complete application message (ifnecessary); the transport layer can send a transport ACK message to thePG 116 that sent the message; it is important to note that, in someexemplary embodiments, sending ACK messages can be optional; and

[0420] 5. When the PG 116 receives the transport ACK from the clientapplication, the PG 116 can send an ACK control message back to the BES122 (via the MR 124) that was the source of the original message (ifrequired).

[0421]FIG. 7B depicts an exemplary embodiment of a message flow diagram702 illustrating transmission of a multi-segment message from BES 122 toa client device 112 according to the present invention. Flow diagram 702can alternatively represent sending of a multi-segment alert from BES122 to a client device 112. Flow diagram 702 can begin with step 704.

[0422] In step 704, BES 122 can transmit a multi-segment messageintended for a client device 112 to MR 124. From step 704, flow diagram702 can continue with step 706.

[0423] In step 706, MR 124 can route the message to an appropriate PG116 as discussed above with reference to FIG. 1C.

[0424] In step 708, the simple network transport layer (SNTL)application running on the PG 116 can segment the message into multiplesegments, can encapsulate the segments with an SNTL segment header 1000,and can transmit the segments of the message to the client device 112.An exemplary embodiment of a message header 1000 is illustrated belowwith reference to FIG. 10. As will be apparent to those skilled in therelevant art, due to a high bit error rate in wireless communicationlinks, it can be expected that potentially not all transmissions from PG116 will be received at the client device 112. From step 708, the flowdiagram can continue with step 710.

[0425] In step 710, client device 112 can send to the PG 116 anacknowledgement (ACK) of receipt of the transmitted messages at theclient device 112. Also, if the message is segmented, an acknowledgementof each segment may be returned. As shown, in the exemplary embodiment,receipt of only segment 1 is acknowledged. Receipt of segment 2 is notacknowledged. From step 710, the flow diagram 702 can continue with step712.

[0426] In step 712, in an exemplary embodiment, PG 116 can automaticallyretry, or retransmit segment 2 of the message to the client device 112,since acknowledgement of receipt was not received for segment 2 in step710. From step 712, flow diagram 702 can continue with step 714.

[0427] In step 714, client device 112 can transmit an acknowledgementthe complete multi-segment message has been received to PG 116. This ispreferably done in connection with sending the acknowledgement of thelast message segment. From step 714, flow diagram 702 can continue withstep 716.

[0428] In step 716, PG 716 can send an acknowledgement of receipt of thecomplete multi-segment message to MR 124. From step 716, flow diagram702 can continue with step 718.

[0429] In step 718, MR 124 can send acknowledgement of receipt of themulti-segment message at the client 112 on to the BES 122. From step718, flow diagram 702 can immediately end.

[0430] The flow diagram 702 can be used in one exemplary embodiment tosend a response from BES 122 to a request originating from client 112.In another exemplary embodiment, flow diagram 702 can be used togenerate an unsolicited response, also commonly referred to as an“alert,” or a “push.” It is important to note that acknowledgement ofreceipt of a response message, as shown for example in flow diagram 702,is optional. For example, in the case of some client devices 112, suchas, e.g., with some paging devices, it may be impossible to send backfrom the client devices 112 an acknowledgment.

[0431]FIG. 8A illustrates a flow diagram 800 depicting an exemplaryembodiment of the present invention. Flow diagram 800 numericallydepicts a flow of messages that corresponds to an alert that can be sentfrom a BES 122 to a client application at client device 112. Flowdiagram 800, in an exemplary embodiment, can proceed similarly to themethod detailed in flow diagram 700 above describing sending a responsemessage to a request. A BES 122 unsolicited alert can be sent to aclient application and can differ only slightly from the response fromBES 122 to a client application. The difference can include that the BES122 is not responding to a specific request and, therefore, does notknow the LinkStation ID of the client application. However the BES 122can know the customer ID or the customer ID and the port number of theclient application running on client device 112. Flow diagram 800 ofFIG. 8A numerically shows an exemplary alert message flow from the BES122 through MR 124 and PG 116 to the client application running on theclient device 112 including several exemplary steps labeled by numbers1-5, as follows:

[0432] 1. a BES 122 can send an unsolicited alert to a clientapplication; the BES 122 can pass the alert message, message flags, nullLinkStation ID and customer/application information on the send call;

[0433] The customer/application information can include the customer IDor the customer ID and the port number of the client application runningon client device 112. Message flags can specify whether to compressand/or encrypt the message and whether the BES 122 requires an ACKmessage when the PG 116 has successfully delivered the message to theclient application. The BES 122 can then send the alert message to thenext available MR 124. If no MRs 124 are available, then a false can bereturned from the send call.

[0434] 2. The MR 124 can use the customer/application information tosend the alert message;

[0435] If the customer/application information includes only thecustomer ID, then the MR 124 can search the local cache of the MR 124and, if necessary, can search the ActiveUsers table to obtain theLinkStation ID associated with the customer ID. If thecustomer/application includes both the customer ID and application portnumber then the MR 124 can search the local cache of the MR 124 and mayalso search the first device assigned to the customer ID in theAuthorizedDevices table to obtain the LinkStation ID. The MR 124 can usethe LinkStation ID to determine a communication type (e.g., CDPD,Mobitex, etc.) associated with the client device and can send themessage to the next available PG 116 of the correct communication type.If the customer/application information includes only the customer IDand the LinkStation ID and these are not found in the local cache orActiveUsers table, the MR 124 may not be able to send the outgoingmessage to the client application with out further information. In thiscase, the MR 124 can send a customer inactive message back to the BES122 that was the source of the outgoing message. If thecustomer/application information is both the customer ID and port numberof the client application running on client device 112, then the messagecan always be sent if a device address is found in the AuthorizedDevicestable for the customer ID.

[0436] 3. The PG 116 can segment the alert into message segments (ifnecessary) and can transmit the alert or message segments over thenetwork;

[0437] 4. The transport protocol layer can receive the alert or messagesegments and can assemble the message segment into a complete alert (ifnecessary); the transport protocol layer can send a transport ACKmessage to the PG 116 that sent the message; it is important to notethat, in some exemplary embodiments, sending ACK messages can beoptional; and

[0438] 5. The PG 116 can receive the transport ACK from the clientapplication running on client device 112, and can send an ACK controlmessage back to the BES 122 that was the source of the original message(if required).

[0439] In an alternative embodiment, the flow of FIG. 8A may differ fromthe flow described above. For example, the difference between a responseand an alert may be that the response message to a request is given aclient information object when the BES 122 receives the request. Thisobject can then be used to send the response as the client informationobject preferably has a LinkStation ID that is hidden in it. When a BES122 sends an alert, the BES 122 should be responsible for constructingthe client information object with the proper information, for example,a customer ID and a device ID (the LinkStation ID that is hidden isnull). The BES 122 needs to know only about the customer ID and deviceID. The device ID is an identifier associated with specific devices. Thedevice ID can be set to an ALL_DEVICES value. This value includes alldevices associated with a particular customer. Thus, the port number ofthe client application is not needed. By setting the customer ID anddevice ID, the BES 122 can target a specific device. If the device ID isset to ALL_DEVICES, then the message will be sent to all of thecustomer's devices.

[0440] Referring again to FIG. 8A, another exemplary alert message flowfrom the BES 122 through MR 124, and PG 116 to the client applicationrunning on the client device 112 including several exemplary stepslabeled by numbers 1-5, will be described:

[0441] 1. A BES can send an unsolicited alert to a client application;the BES can pass the client information object, the alert message, themessage send flags (for example, ACK_REQUIRED, SEND_1F_ACTIVE_ONLY,SEND_ONLY_ONCE), compression flag, and encryption flag on the send call.

[0442] The client information object can include the customer ID anddevice ID. The device ID can be set to a defined value of ALL_DEVICES ifthe BES 122 wants to send the alert to all devices owned by thecustomer. Alternatively, the BES 122 can specify a specific device ID ifthe BES 122 wants to target a specific customer's device. Message flagscan specify 1) whether the BES 122 requires an ACK message when the PG116 has successfully delivered the message to the client application(ACK_REQUIRED flag is set), 2) that the intelligent messaging networkonly try sending the alert if the client is active on the network(SEND_1F_ACTIVE_ONLY flag is set), 3) that the PG 116 should only trysending the message once and not perform retries (SEND_ONLY_ONCE flag isset). The compression flags can indicate if the message needs to becompressed or not and, if so, what algorithm to use. The encryptionflags can indicate if the message needs to be encrypted or not and, ifso, what encryption algorithm to use.

[0443] 2. The MR 124 can use the customer ID and device ID informationto send the alert message;

[0444] The LinkStation ID in the client information object is null sothe MR 124 should use the customer ID and device ID to construct one ormore LinkStation ID(s). The following are 4 possible scenarios.

[0445] 1) If the message send flag is set to SEND_1F_ACTIVE_ONLY anddevice ID is specified, then the MR 124 may first looks in its localcache to obtain the LinkStation ID of the specified device. If thedevice is not found in its local cache, the device could be activewithin the network on some other MR 124. Therefore the MR 124 may lookin an ActiveUsers table to obtain the LinkStation ID of the customer'sdevice.

[0446] 2) If the message send flag is set to SEND_1F_ACTIVE_ONLY anddevice ID is set to ALL_DEVICES, then the MR 124 should only look in theActiveUsers table to obtain the LinkStation ID's of all the customer'sdevices active on the network.

[0447] 3) If the message flag is not set to SEND_1F_ACTIVE_ONLY and thedevice ID is specified, then the MR 124 may first look in its localcache to obtain the LinkStation ID of the specified device. If thedevice is not found in its local cache, then the MR 124 should look inan AuthorizedDevices table to obtain the LinkStation ID.

[0448] 4) If the message flag is not set to SEND_1F_ACTIVE_ONLY and thedevice ID is set to ALL_DEVICES, then all of the customer's device(s)information is retrieved from the AuthorizedDevices table.

[0449] Using the retrieved information, the MR 124 constructs theLinkStation ID(s). If the device(s) are found, either from the cache orthe database, the MR 124 uses the Linkstation ID of each device todetermine the associated communication type (e.g., CDPD, Mobitex) andcan send the message for each LinkStation ID(s) to the next available PG116 of the correct communication type.

[0450] If no device(s) are found, the MR 124 sends a customer inactivemessage if the send message flag is set to SEND_IF_ACTIVE_ONLY.Otherwise the MR 124 can send a customer not valid message back to theBES 122 that was the source of the alert message.

[0451] If ALL_DEVICES is set for the device ID, then once the MR 124 hasfound all the devices for a particular customer, the MR 124 can sendback to the BES 122 each of the device ID's found to correlate anyACK's. This is preferably done before the MR 124 sends the alert messageto the PG 116.

[0452] 3. The PG 116 can segment the alert into message segments (ifnecessary) and can transmit the alert or message segments over thenetwork;

[0453] 4. The transport protocol layer can receive the alert or messagesegments and can assemble the message segment into a complete alert (ifnecessary). Once the transport assembles the message, it will send themessage to any application that have opened the transport and haveexpressed interest in the same type of message as the alert message.Once the message is delivered to the application the transport protocollayer can send a transport ACK message to the PG 116 that sent themessage; it is important to note that, in some exemplary embodiments,sending ACK messages can be optional; and

[0454] 5. The PG 116 can receive the transport ACK from the clientapplication running on client device 112, and can send an ACK controlmessage back to the BES 122 that was the source of the original message(if required).

[0455]FIG. 8B depicts an exemplary embodiment of a flow diagram 802illustrating transmission of a hybrid alert from BES 122 to clientdevices 112 a. 112 b. Flow diagram 802 can begin with step 804.

[0456] In step 804, BES 122 can send a hybrid alert message to MR 124for a client user who can have multiple client devices 112 a. 112 b. Themultiple client devices 112 a. 112 b may operate using differentprotocols and/or different networks. Also, BES 122 can send a messagethat can be delivered to the same client device via alternate paths. Thealternate paths may include sending the message to the same clientdevice using a different protocol on a different network. In anexemplary embodiment, the hybrid alert can include XML query conditions.The query can query, e.g., the MR DB 128 or other database, to determinethe status of particular conditions. For example, the client user mayhave multiple devices as mentioned above. The client user's clientrecord can indicate that redundant alerts should be sent to all devicesat once. Alternatively, the client user's client record could indicate,e.g., that a message should be sent to a primary, or highest prioritydevice first, and if no acknowledgement of receipt of the message fromthe primary device is received, then the message can be sent to asecondary or lower priority device, and so on, in the event that theclient user has multiple client devices. Alternatively, the message canbe sent to the same client device over different protocols or networks.Thus, a single message generated by BES 122 can be delivered to multipleclient devices, sequentially or in parallel, or over multiple paths tothe same client device. The BES 122 need not be concerned with thedifferent protocols, networks, or devices that may be used. From step804, flow diagram 802 can continue with step 806 a or 806 b.

[0457] In an exemplary embodiment, the MR 124 can route the hybrid alertmessage to any of client devices 112 that match the query conditions. Inone exemplary embodiment, the user may have multiple client devices 112a. 112 b. Suppose the criterion are such that the hybrid alert is to besent to both client devices 112 a and 112 b. The hybrid alerts can besent in parallel or sequentially.

[0458] In step 806 a, MR 124 can route the hybrid message to PG 116 a.From step 806 a, flow diagram 802 can continue with step 808 a.

[0459] In step 806 b, MR 124 can route the hybrid message to PG 116 b.From step 806 b, flow diagram 802 can continue with step 808 b.

[0460] In step 808 a, PG 116 a can route the hybrid alert message toclient device 112 a. From step 808 a, flow diagram 802 can continue withstep 810 a.

[0461] In step 808 b, PG 116 b can route the hybrid alert message toclient device 112 b. From step 808 b, flow diagram 802 can continue withstep 810 b.

[0462] In step 810 a, in one embodiment, client device 112 a can sendback to PG 116 a a message acknowledging receipt of the hybrid alertmessage. Acknowledgment of receipt of an alert can be optional. Fromstep 810 a, flow diagram 802 can continue with step 812 a.

[0463] In step 810 b, in one embodiment, client device 112 b can sendback to PG 116 b a message acknowledging receipt of the hybrid alertmessage. Acknowledgment of receipt of an alert can be optional. Fromstep 810 b, flow diagram 802 can continue with step 812 b.

[0464] In step 812 a. in an exemplary embodiment, the PG 116 a canforward on the acknowledgement of receipt at the client device 112 a toMR 124. From step 812 a. flow diagram 802 can continue with step 814 a.

[0465] In step 812 b, in an exemplary embodiment, the PG 116 b canforward on the acknowledgement of receipt at the client device 112 b toMR 124. From step 812 b, flow diagram 802 can continue with step 814 b.

[0466] In step 814 a, in an exemplary embodiment, MR 124 can forward theacknowledgment of receipt on to BES 122.

[0467] In step 814 b, in an exemplary embodiment, MR 124 can forward theacknowledgment of receipt on to BES 122.

[0468]FIG. 8C depicts an exemplary embodiment of a flow diagram 816illustrating a client device 112 a which becomes unavailable whentransmissions are being sent to it, which can prompt a hybrid alert tobe sent to another client device 112 b as shown, e.g., in flow diagram802 of FIG. 8B. The MR 124 may determine that an alternate path isavailable prior to forwarding the request to BES 122. Querying the MRdatabase 128 or another database as described above may do this. Theexistence of alternate paths can then be included in the messageforwarded by the MR 124. The existence of an alternate path is indicatedby the asterisks in FIG. 8C. When a message has an asterisk the messageknows if an alternate path is available. The message may then carry thisinformation around with it from then on. This is shown in steps 820 and830, for example, when the asterisk appears there after the messagepasses through the MR 124. In an exemplary embodiment, only the MR 124has access to the database to determine if an alternate path isavailable, thus the asterisks appear only as a message passes throughthe MR 124.

[0469] Flow diagram 816 can begin with step 818. In step 818, BES 122can attempt to send an alert to MR 124 intended for client device 112 a.From step 818, flow diagram 816 can continue with step 820.

[0470] In step 820, MR 124 can route the alert to a PG 116 a associatedwith client device 112 a. From step 820, flow diagram 816 can continuewith step 822.

[0471] In step 822, according to the exemplary embodiment, supposeclient device 112a is unavailable to receive, and thus a negativeacknowledgement of receipt (NACK) can be sent to MR 124. In oneembodiment, the PG 116 a can be aware that an alternate path can beavailable, i.e., that another client device 112 b with which the BES 122can communicate. This may be done via communication with the MR 124.From step 822, flow diagram 816 can continue with step 824.

[0472] In step 824, the negative acknowledgement (NACK) of receipt atclient device 112 a can be forwarded on from the MR 124 to BES 122. BES122 can be notified in the NACK, in one embodiment, that the BES 122 cansend the alert using a hybrid alert such as, e.g., that depicted in flowdiagram 802 of FIG. 8B, to reach the client user using client device 112b (not shown in FIG. 8C). Alternatively, the BES 122 need not generateanother message and the message router and protocol gateways canautomatically send the alert via an alternate path.

[0473] Flow diagram 816 also depicts a request from client device 112 abeing sent to BES 122 which can begin with step 826.

[0474] In step 826, the client device 112 a can send a request messageto a PG 116 a. From step 826, flow diagram 816 can continue with step828.

[0475] In step 828, PG 116 a can forward the request on to MR 124. Fromstep 828, flow diagram 816 can continue with step 830.

[0476] In step 830, MR 124 can forward the request to BES 122. From step830, flow diagram 816 can continue with step 832.

[0477] In step 832, BES 122 can send a response message intended forclient device 112a to MR 124. From step 832, flow diagram 816 cancontinue with step 834.

[0478] In step 834, MR 124 can route the response message to a PG 116 aassociated with intended recipient, client device 112 a. From step 834,flow diagram 816 can continue with step 836.

[0479] In step 836, suppose that the PG 116 a determines that clientdevice 112 a is unavailable to receive a message, so a negativeacknowledgment of receipt of the response message at the client device112 a can be sent to MR 124. From step 836, flow diagram 816 cancontinue with step 838.

[0480] In step 838, MR 124 can forward on the NACK message to BES 122notifying BES 122 that the response message was not received by clientdevice 112 a. In an exemplary embodiment, BES 122 can be notified thatthe client user can be reached using another client device 112 b. BES122 can be notified in the NACK, that the BES 122 can send the responsemessage using a hybrid alert such as, e.g., that depicted in flowdiagram 802 of FIG. 8B, to reach the client user using client device 112b (riot shown in FIG. 8C). Additionally, the MR 124 may determine clientdevice 112 b is available or that client device 112 a can be reached viaan alternate path. The MR 124 may then automatically send the responseto client device 112 a or 112 b without further instruction from BES122.

[0481] VII. Remote Monitoring of Servers

[0482] To assist in monitoring the intelligent messaging network, asystem and method for publishing information from the servers can beprovided. In this context, the term “servers” can include PG 116, MR124, and BES 122, as well as other servers. A list of available serversaccessible for monitoring by persons, devices, and applications via aremote monitor device can be provided. The remote monitor client mayforward selected servers from the list of available servers in whichthere is interest. Also, particular information about the selectedservers can be requested. Access to the servers and information may berestricted to those with authorization. Authorization can be verified bythe use of digital certificates, as described below. The requestedinformation can then be gathered and provided to authorized persons ordevices. Typically, the information includes logging and statusinformation from the servers. In a preferred embodiment, the informationcan be provided as an XML page and viewed using, for example, a standardweb browser. Further, if the information is provided to the remotemonitor device as an XML page, a standard XML parser may be used toextract particular information about the servers from the XML page. Thisfeature enhances the ability of the remote monitor client to processinformation and perform analysis.

[0483]FIG. 9A depicts in a detailed block diagram an exemplaryembodiment of a system for remote monitoring. PGs 116, firewall 120,BESs 122, MRs 124, SNMP Consoles 134, content provider 140, and internetserver 142 may be provided and connected using WANs/LANs 118 as shown inFIG. 9A. A detailed description of these components and theirarrangement is provided above with respect to FIG. 1A and will not berepeated here. Means 900 may be provided to interface with the serversand obtain the information from the servers. Means 900 can also providean interface with the remote monitor clients 906. In this embodiment,means 900 includes a number of web servers 902-1-902-n. Of course, othermeans for interfacing with the servers can be used. Here, to access theservers, the web servers 902 can be connected to WANs/LANs 118. HTTP maybe used as the protocol to communicate between the web server 902 andthe PGs 116, BESs 122, and MRs 124. Remote monitor clients 906 a, 906 bcan be used to pull the information about the servers from the webserver 902 for analysis and processing. Remote monitor clients 906 a,906 b may be personal computers, workstations, and the like and can beconnected to web servers 902 through a network 904. Network 904 may be,for example, the Internet, a virtual private network, LAN, WAN, etc.HTTP-S is preferably used as the protocol for communication between theremote monitor clients 906 and the web servers 902.

[0484] Additionally, to verify authorization of remote monitor clients906 to access the system, a X.500 and X.400 capable PKI (Public KeyInfrastructure) like Entrust or VeriSign may also be installed on eachof the web servers 902-1-902-n. The PKI is used to facilitate coredigital certificate storage, issuance, and management services, as wellas distribution of certificates and certificate-revocation lists toremote monitor clients 906 and other servers. The remote monitor clientshould have a digital certificate installed on it for the authorizationprocess. Digital certificate management may be privately managed orprovided by a third party certificate server. Other forms of certificateservers (e.g., web certificate servers and wireless certificate servers,which are available from VeriSign, Inc., Mountain View, Calif. U.S.A.)may likewise be deployed on each of the web servers 902.

[0485] In order to better illustrate the remote monitoring process, anexample of the process will be discussed in connection with FIG. 9B.This process may be performed using computer programs running on the webserver 902, remote monitor client 906, and the servers. FIG. 9Billustrates communication exchanges between different components in thesystem during remote monitoring according to an embodiment of theinvention. Typically at the start of the process, a remote monitorclient 906 requests a list of servers available for monitoring, message1. Message 1 is transmitted through network 904 to web servers 902. Theweb servers 902 receive message 1 and begin to assemble the list ofservers. The list of available servers may have been stored in adatabase. The database may be MR database 128 that maintains a list ofavailable servers in the intelligent messaging network, as describedabove in connection with Section I., subsection E. The database isaccessed by the web server 902 to retrieve a list of available servers,message 2. The list of available servers that is eventually provided tothe remote monitor client 906 might include only those servers for whichthat remote monitor client 906 has authorization. An authorization oraccess level to the servers and to information from the servers may beestablished for the remote monitor clients 906. For authorizationpurposes, each remote monitor client 906 can be associated with anaccess level. Verification of access levels may be done using a digitalcertificate containing the necessary authorizations. Accordingly, usingthe PKI described above, the web servers 902 can control access by theremote monitor clients 906 to the servers and information.

[0486] After retrieving the list of available servers from the database,the web server 902 can provide the list to remote monitor client 906,preferably as an XML page. From the list of available servers, theremote monitor client 906 can select those servers in which they have aninterest and provide those selections to web server 902. In addition toselecting servers, the remote monitor client 906 may select the type ofinformation it wants from that server. For example, a remote monitorclient may select to receive only information regarding inbound messagetraffic on a protocol gateway. The selections of servers and informationcan be in the form of HTTP get commands that are transmitted to the webserver 902, message 4.

[0487] Upon receipt of the remote monitor client's 906 selections inmessage 4, the web server 902 begins to dynamically generate a responseincluding the requested information. Initially, to form the response,the web server 902 may examine its cache for the necessary information.If the necessary information is present in the cache, the web server 902can then generate and forward a response to the remote monitor client906, as described below. However, in some situations, the necessaryinformation may not be present in the cache, for example, when a requestis made for information more recent than the information presently inthe cache. The web server 902 may then request the necessary informationfrom an appropriate server. This request may be an HTTP get commandissued from the web server 902 to the appropriate server, for example,PG 116, BES 122, or MR 124. The server receiving this request shouldprovide the required information in response, preferably as an XML page.Messages 5-7 represent communication of requests and responses betweenthe web server 902 and PGs 116, BESs 122, and MRs 124. The informationreceived from the servers in messages 5-7 is then stored in the webserver's 902 cache and is readily available to respond to other requestsfrom the remote monitor client 906. If for any reason a server is notavailable to respond to a request from the web server 902, anappropriate error message is generated.

[0488] After the necessary information is present at the web server 902,the web server 902 can generate a response, message 8, to the remotemonitor client's 906 request, message 4. The response provides therequested information, preferably as an XML page to the remote monitorclient 906, message 8. One advantage of providing the information as anXML page is that information in this form can be viewed using a webbrowser application present on the remote monitor client 906. The webbrowser may display information from one or more servers simultaneously.Also, an XML, parser can be used by the remote monitor client to extractspecific information from the XML page, for example, for logging andanalysis purposes.

[0489] Thus, through network 904, remote monitoring of the flow ofmessages through PG 116, BES 122, or MR 124 or other servers can beaccomplished. Logging and status information can be obtained at remotelocations to monitor and improve performance of the intelligentmessaging network.

[0490] VIII. Software Development Kits

[0491] A. Mobile client SDK

[0492] The Mobile client SDK is comprised of the following set ofplatform specific libraries. Each of the following exemplary librariesexports an easy to use API:

[0493] Utility Library;

[0494] Transport Library; and

[0495] Security Library.

[0496] An exemplary embodiment of the invention, includes a utilitylibrary providing compression services. By keeping the transport libraryindependent from both the utility and security implementation details,new compression and security mechanisms can be added without theknowledge of the transport library. The independence eliminates the needto regression test the transport library, as well as all applicationusers of the transport library when adding a new compression or securitymechanism. Because the compression and security solutions may not meetthe need for all intelligent messaging network enabled applications,when new applications are developed, any specific compression orsecurity requirements of such applications may be accommodatedtransparent to the transport library individually, on a component basis.By providing wrapper APIs that encapsulate the default implementation ofthe utility and/or security libraries, developers could choose to writeto the wrapper APIs, or directly to the utility and/or security APIs.

[0497] 1. Utility Library of the Intelligent Messaging Network

[0498] The utility library of the intelligent messaging network canprovide applications with functions to perform via an easy to use API.The following section summarizes the major functions provided by theutility library.

[0499] A. I/O Streaming

[0500] Provides functions to assist developers with handling applicationmessages that are streaming in and out (two ways). Serial in and outfunctions are provided for most of the common data types supported bythe target platform. The streaming functions manage the big-endianlittle-endian issues on behalf of the application.

[0501] B. Compression Mechanism

[0502] Applications can optionally compress/encode application messagesprior to transmitting the message to a target destination. If the encodealgorithm determines that it is not optimal to encode the message, themessage should not be encoded. Also, applications can optionally decodeapplication messages prior to processing the message. In order todetermine if a message needs to be decoded, applications can check theencode flag contained in the message header.

[0503] C. AIM Message Header

[0504] Every application message should be pre-fixed with theintelligent messaging network message header prior to being sent to itstarget destination. The intelligent messaging network utility libraryprovides applications with functions to set/get the contents of theintelligent messaging network message header. It can also providefunctions to serial out and serial in the contents of the intelligentmessaging network message header. Applications are not required to knowthe internal data representation of the intelligent messaging networkmessage header.

[0505] D. AIMAuthentication Messages

[0506] In order to access the intelligent messaging network via an ISPdialup connection, the intelligent messaging network can require thatthe user provide security credentials to identify themselves. Theintelligent messaging network utility library provides functions tobuild the intelligent messaging network authentication request message.Applications are not required to know the internal data representationof the intelligent messaging network authentication request message,likewise for the intelligent messaging network authentication responsemessage. Functions are provided to determine the authentication statusof the request.

[0507] 2. Transport Library of the Intelligent Messaging Network

[0508] The transport library can provide reliable, optimized datacommunication over various wireless networks, such as the CDPD andMobitex wireless networks, as well as ISP dialup wire line access toenabled the intelligent messaging network client applications via aneasy to use API. The following section summarizes the major functionsprovided by the mobile client transport library.

[0509] Designate Target Destination—The client application can specifythe target destination of the machine to receive the message.

[0510] Notification of Success/Failure of Transmission—The clientapplication receives notification of the success or failure of themessage transmission. For those platforms that support a multi-threadedenvironment (e.g. WinCE), the notification mechanism can be via an eventthat the transport library asserts. For those platforms that do notsupport a multi-threaded environment (e.g. Palm OS), the clientapplication may be required to continuously poll the transport libraryto determine if the message transmission was successful or failed.

[0511] Message Segmentation—All messages that are greater than themaximum segment size (configurable) should be segmented into multiplemessage segments.

[0512] Message Re-Assembly—All multi-segmented messages received arere-assembled into a single message prior to presenting the message tothe client application running on client device 112.

[0513] Message Retries—All message segments that are not acknowledged bythe peer wireless protocol layer within the configured time may beretried the configured number of attempts before notifying the clientapplication that the message was delivered (acknowledgment) or not(negative acknowledgment).

[0514] Configurable Communication Parameters—The communicationparameters for the mobile client transport library can be tailored tothe required communication behavior. These values can be configured viathe registry (WinX platforms) or the preferences database (Palm OSplatforms) prior to opening the mobile client transport library.

[0515] Duplicate Message Segment Detection—All duplicate messagesegments received by the mobile client transport library can beacknowledged back to the peer wireless protocol layer, discarded, andconditionally logged.

[0516] Duplicate Message Detection—All duplicate messages received bythe mobile client transport library can be acknowledged back to the peerwireless protocol layer, discarded, and conditionally logged.

[0517] A layered architecture can be used for developing the transportlibrary. Under this arrangement, each layer (excluding the bottom) canencompass certain functions, can request services from the layerdirectly below it, and each layer (excluding the top) can provideservices to the layer directly above it. In order for a layer to do thejob it is assigned to perform; layer N employs the services of layerN-1. The division of the network into logical layers can allow a higherlevel to make use of the more primitive functions of lower levels,without having the layer concern itself with the implementation detailsof those primitives.

[0518] A. Protocol Stack

[0519]FIG. 3 depicts an exemplary embodiment of a block diagram 300 ofthe present invention. Block diagram 300 illustrates a proprietarywireless protocol stack of the present invention including a mapping tothe layers of the OSI model as illustrated in the left column. Like theTCP/IP protocol stack, the protocol stack of the present inventionincludes only 5 layers. The highest layer is the applications layer,which corresponds to layer 7 in the OSI protocol stack reference model.Layer 4, the transport layer is the proprietary simple network transport(SNTL) layer of the present invention. Layer 3 is the network layer,corresponding to OSI layer 3. Layers one and two of the OSI model havebeen combined in the figure for ease of reference and include the datalink and physical layers for a variety of supported protocols forspecific classes of client devices. Because symmetry is assumed, each ofthe PGs 116 has a symmetrical protocol stack. Each client device 112 canhave only one of the combination layers corresponding to OSI layers oneand two. Similarly, while each of the PGs 116 could have one or more ofthe layers corresponding to the combination OSI layer one and two, anexemplary embodiment can include for each PG 116 having only onecombination layer corresponding to layer one and two.

[0520] i. Application Layer

[0521] The function of application layer (layer 7 of the OSI stack) isto provide an interface between the application and the transportprotocol layer by which client applications can send and receivemessages across multiple wireless networks (or via dial-up ISP access)without having knowledge of the communication implementation.

[0522] In an exemplary embodiment of the present invention, layers 4 caninclude, e.g., applications such as, e.g, mail, file transfer, and otherapplications such as, e.g., end user applications.

[0523] ii. Transport Layer

[0524] This layer logically represents layer 4 of the reference modelfor the present invention. This layer provides the control structure formanaging the communications between two communicating peer transportlayers. The following sections detail the functions provided by thisprotocol layer.

[0525] The highest layer is the application layer. Layer 4 is thetransport layer and, in an exemplary embodiment, includes aconnectionless UDP-like transport protocol that has many of the featuresand advantages of TCP. That is, the transport layer is connectionlesslike UDP but has many of the features of TCP including but not limitedto message segmentation, message segment reassembly, message retries,and message duplication but has only a four to six byte header.

[0526] In an exemplary embodiment of the present invention, layers 4 caninclude, e.g., the simple network transport layer (SNTL) protocol of thepresent invention.

[0527] iii. Lower Layers

[0528] The network layer (layer 3) such as, e.g., the Internet Protocol(IP) layer is responsible for providing network protocol layerfunctionality and hiding the details of this functionality from thetransport layer. Below the network protocol layer is the data linkprotocol layer (layer 2) and finally the physical protocol layer, whichhandles modulation and radio transmission.

[0529] In an exemplary embodiment of the present invention, layers 1 and2 can include any of, e.g., the PSTN 308 a, CDPD 308 b, Mobitex 308 c,Ardis 308 d, GPRS, and other, and future protocols 308 e, and GSM 308 f.

[0530] Message Segmentation

[0531] All messages to be sent over the network that exceed the maximumsegment size (configurable) are segmented into multiple messagesegments. The segment size is configured prior to the client applicationopening the transport library. The default maximum segment size is 512bytes.

[0532] Segment Header

[0533] A transport header is prefixed to every outbound message segment.The transport header is encoded in network-byte order. It is the soleresponsibility of the application to encode any application specificdata in network-byte order prior to calling the AeTransportSendinterface function. The diagram below details the transport headerfields.

[0534]FIG. 10 illustrates a diagram 1000 illustrating an exemplaryembodiment of the present invention. Diagram 1000 depicts an exemplaryembodiment of an exemplary segment header and exemplary components1002-1010 of the header. In an example embodiment, a type I header caninclude a single segment message header, and a type II header caninclude a multiple segment message header. It will be apparent to thoseskilled in the relevant art, that various other header formats can beused within the spirit and scope of the present invention.

[0535] VER 1002

[0536]

[0537] This field contains the version number of the Segment Header. Itconsists of two bits, bit 0 and bit 1 of the 1^(st) word in the SegmentHeader. Valid values are 0 through 3.

[0538] MESSAGE ID 1004

[0539] This field contains a message identification value. It consistsof thirteen bits, bits 2 through 14 of the 1^(st) word in the segmentheader. Valid values are 0 through 8,192. The transport protocol layeruses the message ID to discard segment/message duplications and to matchacknowledgments with messages.

[0540] FLAGS 1006

[0541] This field contains protocol information. It consists of fivebits, bits 15 through 19. Valid values are:

[0542] Bit 19—segmentation indicator (0—message not segmented,

[0543]1—message segmented)

[0544] Bit 18—reserved

[0545] Bit 17—reserved

[0546] Bit 16—message type (0—positive acknowledgment, 1—negativeacknowledgment)

[0547] Bit 15—message indicator (0—application message, 1—AIM controlmessage)

[0548] TOTAL LENGTH 1008

[0549] This field contains the total number of bytes contained in themessage segment to be sent including the segment header. It consists oftwelve bits, bits 20 through 31 of the 2^(nd) word in the segmentheader. Valid values are 4 through 4,096.

[0550] SEGMENT NUMBER 1010

[0551] This field identifies the number of this message segment. Itconsists of 8 bits, bits 0 through 7 of the 3^(rd) word in the segmentheader. Valid values are 2 through 255. The peer wireless protocol layeruses this number to re-order the message segments into a single completemessage. In a preferred embodiment, his field is present only if thesegmentation indicator is set in the flags field.

[0552] Notification of Success/Failure of Transmission

[0553] The transport protocol layer retains knowledge of all outstandingmessage segments pending acknowledgment (message segments that have notbeen acknowledged by the peer wireless protocol layer) via a pendingacknowledgment queue. The pending acknowledgment queue maintainsinformation pertaining to message segments that have been successfullytransmitted and are pending acknowledgment from the peer wirelessprotocol layer. If an acknowledgment (positive or negative) is receivedfor a message segment that is not pending acknowledgment, the ACK isdiscarded and conditionally logged.

[0554] When all message segments have been positively acknowledged bythe peer wireless protocol layer, the application is notified (ifrequested) with a message type of AIM_ACK_MESSAGE and the message IDvalue associated with the sent message. If the number of transmissionattempts for the message segment has exceeded the configured number ofretry attempts, the application is notified with a message type ofAIM_NACK_MESSAGE, the message ID value associated with the sent message,and the 2 byte error code containing the reason why the message was notdelivered. In order to re-send a message that has been negativelyacknowledged, the application calls a AeTransportSend interfacefunction.

[0555] Message Retries

[0556] All message segments not acknowledged by the peer wirelessprotocol layer within the configured time are automaticallyre-transmitted. The time to wait for an acknowledgment from the peerwireless protocol layer is configured prior to the client applicationopening the transport library. The default time to wait for anacknowledgment from the peer wireless protocol layer can for example be15 seconds.

[0557] The transport protocol layer retries the configured number oftimes before notifying the application that the message could not bedelivered (negative acknowledgment). The number of times to retry isconfigured prior to the client application opening the transportlibrary. The default number of retry attempts is 3.

[0558] Message Re-Assembly

[0559] All incoming message segments received (including duplicatesegments) are immediately acknowledged back to the peer wirelessprotocol layer and are queued pending receipt of all message segmentsvia the inbound message queues. The incoming message queues manages aseparate inbound message queue for each different LinkStationID of thesender.

[0560] When all message segments have been received for a message, thesegments are assembled into a complete message. If the message ID of theassembled message has been already received (duplicate message), themessage is discarded and conditionally logged. This layer keeps track ofthe last n message IDs received for each unique LinkStationID. Thenumber of message IDs to contain in the message look back queue isconfigured prior to the client application calling AeTransportOpen toopen the transport library. The default number of message IDs tomaintain in the message look back queue may be set to 10, for example.

[0561] The exemplary message header 1000 of FIG. 10 includes segmentnumber field 1010 which can be used to identify the segment number of amulti-segment message. For multiple segment messages, an additionalfield (not shown) can be used to identify the total number of segmentsin a message. In an exemplary embodiment, the total number of segmentsfield could be 2 bytes wide. Advantageously, according to an exemplaryembodiment of the present invention, the simple network transport layer(SNTL) can use the information in the total number of segments field todetermine which segments of the total number sent were received asacknowledged, or are required to be retransmitted. The reader isdirected to FIGS. 6B and 7B above illustrating transmitting amulti-segment message, and retrying where a segment is not acknowledged.

[0562] 3. Security Library of the Intelligent Messaging Network

[0563] The security library can provide encryption and decryptionservices to the intelligent messaging network enabled applications viaan easy to use API. The following section summarizes the major functionsprovided by the security library.

[0564] Key Exchange—Public and private keys may be used periodically toestablish a common secret key that both the client application runningon a client device and server use when exchanging messages. The reasonfor this is that the overhead of encrypting using public/private keys ismuch higher than when using a single secret key. The message flows tosecurely establish a secret key between a client application running ona client device and a server is the responsibility of the securitylibrary.

[0565] Encryption—Mobile client application running on a client devicecan optionally encrypt application messages prior to transmitting themessage to the target destination. Messages are encrypted with thesecret key negotiated between the client application running on a clientdevice and the server. Encryption is preferably always performed aftercompression.

[0566] Decryption—Mobile client applications running on a client devicecan optionally decrypt client application messages prior to processingthe message. To determine if a message needs to be decrypted, clientapplications can check the encryption flag contained in the messageheader. Messages are decrypted with the secret key negotiated betweenthe client applications running on a client device and the server.Decryption is preferably always performed before compression.

[0567] B. Server Software Development Kit (SDK)

[0568] The Intelligent messaging network provides a server SDKenvironment to assist engineers developing PGs 116 and BESs 122. Theserver SDK can be comprised of an easy to use C++API and a set ofWindows NT 4.0 libraries. The SDK can be logically divided into thefollowing two categories of classes:

[0569] 1. Server classes—These are the core classes that serverapplication developers use when creating new PGs 116 and BESs 122. Theseclasses may have no Graphical User Interface (GUI); thereby allowingdevelopers to provide their own custom interfaces.

[0570] 2. Server user interface classes—These classes provide agraphical interface to the Server classes. Use of these classes is notrequired when developing a new Server.

[0571] AIM Server Classes

[0572] The Server classes can be organized in the following simple classhierarchy:

[0573] AeServer Class

[0574] The AeServer class is the base class for all of the other Serverclasses and encapsulates those functions that are common to all Servers.These include:

[0575] Server Registration/Deregistration—Server subclassesregister/de-register from the intelligent messaging network MR database128 themselves, using methods defined in this class.

[0576] Server to Server Connectivity—The logic that determines how twoServers locate and connect to one another is implemented in the AeServerclass. The connection flow consists of both establishing a TCP/IPconnection as well as the mutual exchange of ServerConnect messages as ameans of verifying the identify of each server.

[0577] Server to Server Communication (TCP/IP)—AeServer encapsulates theTCP/IP communication between all Servers. Servers can use thecommunication functions provided by this class to connect, disconnect,send messages, and receive messages over a TCP/IP connection to otherServers. The AIMSvrPacket can be used as the standard unit ofcommunication between all Servers. The sequence of same fields that maycomprise the AIMSvrPacket are as follows:

[0578] AIMSvrPacket Layout

[0579] Version (4 bits)—The version number of the AIMSvrPacket.

[0580] Header Length (4 bits)—The length of the AIMSvrPacket header inbytes. The AIMSvrPacket header consists of the first 5 fields of theAIMSvrPacket: version, header length, flags, total packet length andsource server ID. This length is used by the TCP connection classes toread enough of the packet in order to determine the total size of theremainder of the packet.

[0581] Flags (BYTE)—contains protocol information. It consists of eightflag bits, valid values are:

[0582] Bit 1—acknowledgment indicator (1—ACK required, 0—ACK notrequired)

[0583] Bit 2—message type indicator (1—server connect message)

[0584] Bits 3-8—reserved for future use.

[0585] Total Packet Length (unsigned long)—Contains the total number ofbytes in the AIMSvrPacket (including the packet header).

[0586] Source Server Database ID (unsigned long)—Contains Database ID (aunique value assigned to a server when the server registers itself inthe intelligent messaging network MR database 128 of the originator ofthe packet.

[0587] LinkStationID (variable length)—Contains the device address ofthe source or destination of the message contained in the packet. Thisfield's size and content varies depending on the communications type(CDPD, Mobitex, etc) of the device.

[0588] Message ID (unsigned short)—server packet message identifier.

[0589] Customer ID (unsigned long)—intelligent messaging network MRdatabase 128 ID of the customer who owns the device targeted by themessage in the server packet. Although preferably always present, thisfield does not always contain a valid value and is set to 0 when notvalid. This field is not valid when the AIMSvrPacket contains a networkcontrol message (server-to-server messages independent of applicationmessages) or when passing a client message to/from a PG 116 and MR 124.The primary purpose of the field is for MR 124 to BES 122communications, to identify the message source on incoming messages, andtarget a specific customer device on outgoing messages.

[0590] Port Number (unsigned short)—customer device port number.Although preferably always present in the packet, this field onlycontains a valid (non-zero) value when a BES 122 sends an unsolicitedmessage to a device.

[0591] Intelligent Messaging Network Message Header (in an exemplaryembodiment can include 6 BYTES)—All application messages should prefixthe intelligent messaging network message header to the beginning of theapplication message. The intelligent messaging network message headermay consist of the following fields:

[0592] 1. Compression Bits (3-bits)—0=message is not compressed,1=System supplied compression type, 2=supplier supplied compressiontype, 3=application supplied compression type.

[0593] 2. Security Bits (3-bits)—0=message is not encrypted, 1=Systemsupplied encryption, 2=Supplier supplied encryption, 3=applicationsupplied encryption.

[0594] 3. Version (3-bits)—Message header version.

[0595] 4. Reserved Bits (7-bits)—Reserved for future versions.

[0596] 5. Service Type (12-bits)—Identifies which type of service(MarketClip, FX) the message pertains to. This field is used by bothindirect and direct routing.

[0597] 6. Message Type (12-bits)—Uniquely identifies the message withinthe context of the specified service type.

[0598] 7. Server ID (1-byte)—Identifies a specific BES 122 of the givenservice type. The value of 0 is reserved to indicate that indirectrouting is desired. A non-zero value indicates that the message istargeted at a specific BES 122.

[0599] Message Body (variable length)—Contains the body of theapplication message. AeFEServer Class (for the PGs)

[0600] The AeFEServer class subclasses AeServer and encapsulates thosefunctions that are common to all PGs 116. All PGs 116 should be derivedfrom the AeFEServer class. This class may perform the followingfunctions on behalf of all PGs 116:

[0601] Encapsulates the Transport Header—Only this class preferablyknows the implementation details of the transport header. The transportheader contains control information for communicating between theintelligent messaging network enabled client applications and PGs 116.

[0602] Asynchronous (non-blocking) Notification of Success/Failure ofTransmission—This class optionally notifies the original sender of themessage indication of the success or failure of the message transmittedto the client application running on client device 112.

[0603] Message Segmentation—All outbound server messages to be sent tothe client application that are greater than the maximum segment size(configurable) can be segmented into multiple message segments.

[0604] Message Re-Assembly—All multi-segmented messages received fromthe client application can be re-assembled into a single message priorto sending the message to a MR 124 to route to a registered BES 122.

[0605] Message Retries—All message segments that are not acknowledged bythe client device peer wireless protocol layer within the configuredtime can be retried the configured number of attempts before notifyingthe original sender that the message was delivered (acknowledgment) ornot (negative acknowledgment).

[0606] Message Pacing—For large multi-segmented messages, many devicemodems cannot keep up if they are quickly flooded with a series ofsegments. PGs 116 contain a configurable setting that can be set to slowup the transmission of messages larger than a specified number ofsegments.

[0607] Duplicate Message Segment Detection—All duplicate messagesegments received from the client device are acknowledged back to theclient device peer wireless protocol layer, discarded, and conditionallylogged.

[0608] Duplicate Message Detection—All duplicate messages received fromthe client device can be acknowledged back to the client device peerwireless protocol layer, discarded, and conditionally logged.

[0609] Configurable Communication Preferences—The communicationparameters for the PG 116 can be configured to tailor the communicationbehavior. These values are configured prior to the starting the PG 116.

[0610] AeBEServer Class

[0611] The AeBEServer class subclasses from AeServer and can encapsulatethose functions that are common to all BESs 122. This class may performsthe following functions on behalf of all BESs 122:

[0612] Generate ACK Control Messages—When this class receives anincoming from a PG 116 routed via MR 124, it can create an ACK controlmessage and send it back to the originating PG 116 via a MR 124. Whenthe PG 116 receives this ACK control message, it sends a transport layerACK message to the client application on a client device that originatedthe message indicating that the message was delivered to the BES 122.

[0613] Process ACK Control Messages—When this class receives an ACKcontrol message from a PG 116, indicating that the server applicationmessage was delivered to the client device, it notifies the derived BES122.

[0614] Message Compression/Decompression—AeBEServer is responsible forcompressing any outgoing messages and decompressing incoming messages.If an AIM provided compression type is involved,compression/decompression is done transparently relative to anysubclasses of this type. Alternately, AeBEServer subclasses mayimplement compression in their message serialization.

[0615] Message Encryption/Decryption—AeBEServer is responsible forencrypting any outgoing messages and decrypting incoming messages. If anAIM provided encryption type is involved, encryption/decryption is donetransparently relative to any subclasses of this type. Alternately,AeBEServer subclasses may implement their own encryption algorithms byimplementing the appropriate virtual methods that is invoked byAeBEServer at the appropriate times.

[0616] DerivedPGs 116

[0617] All the intelligent messaging network developed PGs 116 should bederived from the AeFEServer class. Derived PGs 116 may provide thefollowing functions:

[0618] Encapsulate the Communication Layer—Derived PGs 116 provide thenetwork specific interface to the communication layer used by the PG116. The parent class (AeFEServer) does not know the implementationdetails of the underlying protocol layer used to send and receivemessages to and from client applications running on client devices 112.This is the sole responsibility of the derived PG 116.

[0619] Derived BESs 122

[0620] All BESs 122, developed by the intelligent messaging network canbe derived from either the AeBEServer. Derived BESs 122 may provide thefollowing functions:

[0621] Process application Specific Messages—All application specificknowledge is implemented in the derived BES 122. For example, a newsservice can provide client devices with news stories related to aspecific financial entity. The derived new services' parent classhierarchy (AeBEServer and AeServer) does not know the implementationdetails of the application message protocol. This is the soleresponsibility of the derived BES 122.

[0622] Special Compression Services—If a BES 122 has specificcompression requirements for their application data that is notaddressed by the Intelligent messaging network supplied compression, theBES 122 is responsible for providing the compression mechanism.

[0623] Special Security Services—If a BES 122 has specific encryptionrequirements for their application data that is not addressed by theIntelligent messaging network supplied encryption, the derived BES 122is responsible for providing the encryption mechanism.

[0624] Server User Interface Classes

[0625] The server user interface class hierarchy parallels the serverclass hierarchy and provides the following types of functionality:

[0626] 1. Persistent storage of configurable server settings as well asa common user interface for viewing/editing those settings.

[0627] 2. Screen based error logging.

[0628] 3. NT Event Log error logging and automatic batch file errornotification.

[0629] 4. Inbound/outbound message logging.

[0630] 5. Inbound/outbound message statistics.

[0631] AeServerApp

[0632] AeServerApp is the base class for all of the other server GUIapps. All server applications are complete, windows-based, executableprograms. AeServerApp expects its subclasses to provide it with aninstance of an AeServer subclass. Of the five areas of functionalitylisted above, AeServerApp may provide the following:

[0633] 1. Persistent storage of configurable server settings and commonuser interface framework for viewing/editing those settings.—Persistentstorage is implemented through the Windows registry and AeServerAppprovides the base registry key for all of its subclasses to use.AeServerApp also provides a standard method of viewing/editing serversettings in the form of a PropertySheet. Subclasses provide for theirown individual server settings by adding PropertyPages to the base classPropertySheet. AeServerApp provides a common page for handling serversettings common to all server types.

[0634] 2. Screen based error logging.—In addition to providing a windowwhere system events and errors can be displayed, AeServerApp alsosupplies a separate logging thread that can be used by subclasses whendisplaying output to their own windows. This thread runs at lowerpriority then the server processing threads so that screen logging doesnot negatively impact performance.

[0635] 3. NT Event Log error logging and automatic batch file errornotification. AeServerApp provides a mechanism whereby system errors canbe written to the NT Event log. The level of error reporting isconfigurable. In addition to the NT Event log, users may specify that abatch file be executed when an error of a specified severity occurs.Such batch files could be used to communicate problems to a systemadministrator via email or a pager.

[0636] AeFEServerApp

[0637] AeFEServerApp is derived from AeServerApp and may provides thefollowing additional user interface features:

[0638] 1. PG specific server settings—Preferably provides a userinterface and persistent storage for transport settings such as maximumnumber of retries, retry timeout interval, segment size, etc.

[0639] 2. Inbound/Outbound message logging—Provides two windows that logeach inbound and outbound message. Makes use of the AeServerApp loggingthread. Logging may be enabled/disabled for either window.

[0640] 3. PG specific statistics—Gathers and displays statistical totalssuch as number of messages sent/received, number of ACKS/NACKSsent/received.

[0641] AeBEServerApp and CBEServerSampleApp

[0642] These classes provide a standard GUI for BESs 122. Both arederived from AeServerApp and should both provide the same set of userinterface features. The difference between the two classes is thatCBEServerSampleApp also derives from AeBEServer, while AeBEServerApp hasa AeBEServer member (inheritance vs aggregation). Other than that thetwo classes provide the same set of features:

[0643] 1. Inbound/Outbound message logging—Preferably provides twowindows that log each inbound and outbound message. Makes use of theAeServerApp logging thread. Logging may be enabled/disabled for eitherwindow.

[0644] 2. Back-End specific statistics—Gathers and displays statisticaltotals such as number of messages sent/received, number of ACKS/NACKSsent/received, and compressed vs. uncompressed byte totals.

[0645] 3. Application message log view—Provides an additional loggingwindow that applications should use to log their own errors or tracestatements rather than intermingling them with the system messages inthe system log window.

[0646] C. Wizards and Resource Kit of the Intelligent Messaging Network

[0647] In a well-known manner, intelligent messaging network can alsoprovide tools that work in conjunction with the Microsoft VisualDeveloper Studio framework. These tools assist engineers developingclient and BES 122 applications, as well as stress test and monitor thehealth of the intelligent messaging network.

[0648] 1. Message Builder Wizard

[0649] The Intelligent messaging network Message Wizard makes it easyfor developers to define their application specific data content of theintelligent messaging network messages. The wizard makes it easier forthe developer to focus on adding business value to their applicationinstead of having to worry about the tedious and error prone task ofwriting the serialization code to transfer message content betweenserver and client. It also can automatically generate the code needed toserialize the message content between a client application and a BES 122application.

[0650] 2. Back End Server App Wizard

[0651] The BES 122 App Wizard can make it easy for developers to createBES 122 applications. The BES 122 App Wizard can generate the VisualStudio C++project and its associated program and header files to createa BES 122 executable. BES 122 developers would then need to add programlogic to support their application protocol.

[0652] 3. Ping App Wizard

[0653] In order to assist engineers developing a BES 122 Pingapplication, the intelligent messaging network Ping App Wizard makes iteasy for developers to create a Ping BES 122 executable. The Ping AppWizard can generate the Visual Studio C++project and its associatedprogram and header files to send an application defined “heart beat”message to a BES 122. BES 122 developers may want to use this tool as away to monitor the health of their BES 122.

[0654] IX NT client Simulation Application

[0655] In order to assist engineers developing BES 122s, the intelligentmessaging network can also provide a client simulation application.Developers can use the client simulation application to simulatemultiple clients and to generate BES 122 specific message traffic. Theclient simulation application supports the following major functions:

[0656] Simulate up to 256 clients

[0657] Support multiple communication networks

[0658] CDPD

[0659] Mobitex

[0660] Dial-Up

[0661] TCP/IP LAN

[0662] Configurable simulation attributes

[0663] Number of messages to send

[0664] Application defined messages

[0665] Relative send frequencies for each message type

[0666] Compression

[0667] Capture/present performance statistics

[0668] Total messages sent

[0669] Average message response time

[0670] From the forgoing description it may be appreciated that thepresent invention provides protection against technology obsolescence bysupporting seamless integration of information sources with multiplewireless networks and client devices. As such, the invention provides areliable method of data transfer, while optimizing bandwidth constraintof wireless data services and providing end-to-end security. Thisinvention allows for system growth by incorporating the new devices andwireless network technologies as they become available, without the needto modify client and server applications.

[0671] The above-described environment, which has a messaging basearchitecture, serves as the framework for implementation of theinvention. This environment can provide client/server connectivity,which can provide an enabling mechanism for application networkconnection connectivity. The architecture can support messaging.Platform transparency can be provided enabling platform independence ofclient devices. Network transparency can be provided by an enablingmechanism for network independence by hiding the underlining networkprotocol. The SDK can provide an easy to use developers tool kit andenvironment for the design development of each aspect of theapplication, the client device, and server.

[0672] Accordingly, the SKDs can provide a standard communicationinterface to allow clients and servers to interact with multiplewireless networks in a unified manner. This allows applicationdevelopers to concentrate on business logic, not writing wirelesscommunication software.

[0673] While various exemplary embodiments of the present invention havebeen described above, it should be understood that they have beenpresented by way of example only, and not limitation. Thus, the breadthand scope of the present invention should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. In a messaging system communicating a messagebetween a client device and servers over a plurality of wirelessnetworks, each of which is adapted to support one or more wirelessnetwork protocols, and wherein a web server communicates with theserver, a method for monitoring status of the server with remote monitorclients, the method comprising: publishing a list of available serversto the remote monitor clients; receiving servers selected from the listof available servers from the remote monitor clients; dynamicallygenerating information about the selected servers with the web server;and providing the dynamically generated information from the web serverto the remote monitor clients.
 2. The method according to claim 1 ,further comprising retrieving the list of available servers from adatabase with the web server.
 3. The method according to claim 2 ,wherein the database is a message router database.
 4. The methodaccording to claim 1 , wherein the dynamically generating stepcomprises: examining a cache of the web server for the information; andif the information is not present in the cache, retrieving theinformation from the selected server and storing the information in thecache.
 5. The method according to claim 1 , further comprising,receiving a request for selected information from the selected servers.6. The method according to claim 5 , wherein the dynamically generatedinformation is the selected information.
 7. The method according toclaim 1 , further comprising: determining an access level of the remotemonitor client to receive information; and providing only informationcorresponding to the access level to the remote monitor client.
 8. Themethod according to claim 7 , wherein the determining step comprises:issuing the remote monitor client a digital certificate; associating thedigital certificate with the access level; and examining the digitalcertificate.
 9. The method according to claim 1 , wherein thedynamically generated information is provided as an XML page.
 10. Themethod according to claim 1 , wherein the list of available servers isprovided as an XML page.
 11. The method according to claim 1 , whereinthe dynamically generated information includes at least one of loggingand status information.
 12. The method according to claim 1 , whereinthe web server and remote monitor client communicate over a networkutilizing HTTP-S.
 13. The method according to claim 7 , wherein the listof available servers only includes servers a particular remote monitorclient is authorized to view.
 14. The method according to claim 1 ,wherein the servers and the web server communicate utilizing HTTP. 15.The method according to claim 14 , wherein the dynamically generatingstep comprises issuing a get command from the web server to the serversto obtain the information.
 16. The method according to claim 15 ,further comprising, in response to the get command, providing an XMLpage including the information to the web server from the servers. 17.The method according to claim 16 , further comprising generating an XMLpage containing the selected information at the server.
 18. The methodaccording to claim 1 , wherein the servers include at least one of aprotocol gateway, a message router, and a back-end server.
 19. Themethod according to claim 5 , wherein the receiving step comprisesreceiving from the remote monitor client a get command for theinformation at the web server.
 20. In a messaging system communicating amessage between a client device and servers over a plurality of wirelessnetworks, each of which is adapted to support one or more wirelessnetwork protocols, and wherein a web server communicates with theservers, a method for monitoring status of the servers with remotemonitor clients, comprising: receiving a list of available servers atthe remote monitor client from the web server; selecting servers fromthe list of available servers; transmitting a list of selected serversfrom the remote monitor client to the web server; and receivinginformation about the selected servers at the remote monitor client fromthe web server.
 21. The method according to claim 20 , furthercomprising displaying the information at the remote monitor client witha browser.
 22. The method according to claim 21 , further comprisingdisplaying information from more than one servers simultaneously withthe browser.
 23. The method according to claim 20 , wherein theinformation is received as an XML page.
 24. The method according toclaim 23 , further comprising parsing the XML page with a parser toobtain selected information.
 25. The method according to claim 20 ,wherein the list of available servers is received as an XML page. 26.The method according to claim 20 , wherein the information includes atleast one of logging and status information.
 27. The method according toclaim 20 , wherein the web server and remote monitor client communicateover a network utilizing HTTP-S.
 28. The method according to claim 20 ,wherein the list of available servers only includes servers a particularremote monitor client is authorized to view.
 29. The method according toclaim 20 , further comprising requesting specific information about theselected servers from the web server.
 30. The method according to claim29 , wherein the requesting step comprises issuing a get command fromthe remote monitor client to the web server to obtain the specificinformation.
 31. The method according to claim 30 , further comprising,in response to the get command providing an XML page including thespecific information from the web server to the remote monitor client.32. The method according to claim 20 , wherein the servers include atleast one of a protocol gateway, a message router, and a back-endserver.
 33. A remote monitoring system, comprising: a client device; aserver having stored therein a server application, which is adapted tobe executed by the server; a plurality of wireless networks, each ofwhich is adapted to: communicate messages between the client device andthe server; and support one or more wireless network protocols; aprotocol gateway encapsulating a fundamental network protocol, whichunderlies each of the one or more wireless network protocols; at leastone message router for routing the message between the protocol gatewayand the server; and means for providing status and logging informationfrom at least one of the server, protocol gateway, and message router toa remote monitor client.
 34. The system of claim 33 , wherein the meansfor providing information comprises at least one web servercommunicating with the remote monitor client and at least one of theserver, the protocol gateway, and the message router.
 35. The system ofclaim 34 , wherein the web server further comprises means for compilinga list of available servers, protocol gateways, and message routers andproviding the list to the remote monitor client.
 36. The system of claim35 , further comprising means for gathering requested information fromat least one of the server, protocol gateway, and message router andproviding the requested information to the remote monitor client. 37.The system of claim 33 , wherein the information is provided to theremote monitor client as an XML page.
 38. The system of claim 35 ,wherein the list is provided to the remote monitor client as an XMLpage.
 39. The system of claim 33 , wherein communication between the webserver and the server, the protocol gateway, and the message router isperformed using HTTP.
 40. The system of claim 33 , wherein communicationbetween the web server and the remote monitor client is performed usingHTTP-S.
 41. In a communications system including a server, which isadapted to run a server application, a plurality of message routers,each of which is coupled to the server, a plurality of protocolgateways, each of which is coupled to each one of the plurality ofmessage routers, a wireless network, which is adapted to couple theserver, through one or more of the plurality of message routers and oneor more of the plurality of protocol gateways, to a plurality of clientdevices, and a web server communicating with the server, the protocolgateways, and the message routers, a computer useable informationstorage medium storing computer readable program code means for causinga computer to perform the steps of: publishing a list of availableservers to the remote monitor clients; receiving selected servers fromthe remote monitor clients; dynamically generating information about theselected servers with the web server; and providing the dynamicallygenerated information from the web server to the remote monitor clients.42. The a computer useable information storage medium according to claim41 , further comprising computer readable program code means for causinga computer to perform the steps of: retrieving the list of availableservers from a database with the web server.
 43. The a computer useableinformation storage medium according to claim 41 , further comprisingcomputer readable program code means for causing a computer to performthe steps of: examining a cache of the web server for the information;and if the information is not present in the cache, retrieving theinformation from the selected server and storing the information in thecache.
 44. The a computer useable information storage medium accordingto claim 41 , further comprising computer readable program code meansfor causing a computer to perform the steps of: determining an accesslevel of the remote monitor client to receive information; and providingonly information corresponding to the access level to the remote monitorclient.